Improve the handling of long worker requests

[daveyarwood]

Follow-up to #258.

Currently, the client has a hard-coded timeout of 3 seconds when handling an alda play command.

This works fine when handling a request that will take less than 3 seconds, but for larger scores, the client will incorrectly conclude that the server is "down" and exit. Behind the scenes, the request is still being handled and the user will hear the audio once it's ready to start playing.

A better solution would be for the client to handle the request in stages, based on responses from the worker.

Example 1: a short score taking < 100 ms to process

• Client makes alda play request
• Worker handles parsing + evaluating the score in < 1 second, responds with "playing" status
• Client prints "Playing..." and exits

Example 2: (extreme case) a very long score taking seconds to process

• Client makes alda play request
• Worker takes > 1 second to parse, responds with "parsing" status
• Client prints "Parsing...", makes another request for status
• Worker is still parsing, responds with "parsing" status
• Client already printed "Parsing..." so doesn't do it again, makes another request for status
• Worker is evaluating now, responds with "evaluating" status
• Client prints "Evaluating...", makes another request for status
• Worker is playing now, responds with "playing status"
• Client prints "Playing..." and exits

If at any point the client does not get a status response from the worker within an acceptable timeframe, it can make a "ping" request to the server to see if the server is down or not. That way, it can either ask the user to restart the server, or it can maybe let the user know that the worker is down for some reason and try again with another worker.

[daveyarwood]

Another idea I had:

• The client could open a one-off SUB socket connection before making a play request, and include the port number in the request body.
• Whichever worker handles the request can open a PUB connection on that port and publish live updates about where it is in the pipeline. Each update is a JSON string response as usual, but perhaps with an extra field like "pending": true.
• The client can listen for messages on the SUB socket and print out the body of each message as it gets them. If response.pending is true, it can continue to listen for further updates, otherwise it can exit. The last message would be {"success": true, "pending": false, "body": "Playing..."}

(EDIT: I didn't end up doing this)

[daveyarwood]

Fixed in 1.0.0-rc42.