fix: enhance shell() to know when it is interactive

[michaelneale]

This will either return to user and ask them to run it themselves, or ask for more information, or work out how to run it with the information it has. Uses patterns and the accelerator model to supervise command output

fixes: https://github.com/square/goose/issues/49

How this works:

• Watches stdout and stderr
• looks for patterns which may indicate it is blocking for user response
• If there is will return to the user or ask for more input (no blocking)
• If the process doesn't return any output for a time, it examines the log with the acclerator model to see if it may be a long running process and confirm with the user.

For example, both of these are interactive commands now handled:

The former one uses the accelerator model to detect if it is long running or not. Former uses a pattern to detect. Can also log stdout etc now (if we wanted a mode for that) - but you can just ask goose to show you

[michaelneale]

BTW have been using this all week and has been really great

[michaelneale]

@baxen great - not sure if it really matters as a timeout would be triggered but wouldn't necessarily fail (but not sure how to confirm) - the accelerator would then decide or not if to continue (that could probably be enhanced?). There probably could be improvements so it isn't blocking on readline (in case there is no line feeds) and handling things that done return line by line perhaps, but overall, I haven't seen any specific failure modes that made it troublesome for me so far (would want to test it with some hefy tasks, like installs etc).

[baxen]

We discussed a bit about the tradeoff between this occasionally being wrong - if the check model incorrectly identifies the command as stuck, it could interrupt something that was otherwise working. But this appears rare from testing, and seems worth it to catch the more common issue of running a web service