Improved control command interface.

[hjoliver]

Control commands return immediately after queuing a command request to the suite. If the command is successful the user will see the expected result via suite monitoring, but if not (e.g. a supplied task ID regex does not match in tasks in the suite) the suite log must be examined to see what happened.

One idea I've had is to generate a unique ID at the time the request is queued, report it back to the user ("command ade3af99 queued" instead of just "command queued") and then have the suite log the result against the ID. This would allow a --wait option to make the command script wait until the result shows up, and report it, before exiting. Would have to allow for possible log rollover during the wait time (or else use the run-db instead of the log.

[hjoliver]

[meeting] we agreed:

• the command ID would work, possibly with a new command to retrieve the result of a command (given the ID), plus --wait options for all commands.
• some commands should report failure back immediately, e.g. if a task-matching regex does not match any tasks to operate on.
• we should also consider:
  • task-matching regex commands to ask if the matched list of tasks is as intended
  • if a target task is not in the pool, ask if the user wants to insert it
  • auto-insertion (at least with --force), e.g. to retrigger tasks that have been removed from the pool

[matthewrmshin]

In the proposed new web architecture, we should be able to make use of asynchronous 2-way communication to achieve the feedback functionality.

[oliver-sanders]

Merging this with #3329 which proposes pretty much the same thing as proposed here only utilising PUB/SUB to update the client with the command's progress when running interactively.