Create a suspension exception

(imelnikov): Looks like a small and neat addition. My only concern is if it has any nice use cases besides our unit tests.

I mean, why task might want to suspend a flow? The only thing I could come up with is some kind of temporary/non-fatal error condition, like errno=EAGAIN but for tasks. But imo better design here would be to allow task to raise any exception it wants and leave decision to suspend, revert or follow whatever other error handling strategy one might come up with to flow author (yes, I'm speaking about https://blueprints.launchpad.net/taskflow/+spec/reversion-strategies here).

Of course, if I did not come up with good use case it just means that my imagination is kind of limited today, so I'd be glad to change my mind and even implement it if this feature turns out to be useful.

(bkc): A task might want to suspend a flow so that it can wait for an external operation to complete. Consider a flow being used for data processing that involves waiting for external input from another process or a human actor.

e.g. a task submits a job to an external system. The next task in the flow is a re-enterable task that might want to suspend the flow for 5 minutes or until an 'external event' is received (event handling would be defined by the jobboard/conductor). After 5 minutes the logbook could be reloaded, the flow restarted and the re-enterable task executed. At that point the task could decide to wait another 5 minutes, or could see that "the event" had been received, or could raise a regular exception to force a rollback or retry processing.

For this we need some mechanism to:

a. suspend a task

b. signal the flow via an external method

c. resume the suspended task (just re-execute the task, pass some parameters indicating that it's a resume instead of an initial call and possibly indicate which signals were received)

To handle the timeout feature, the 'wake me up in xx seconds' value could be included as part of the 'SuspendTask' exception.
----------
[mp] A suspend and resume would be great, but a true "resume" doesn't seem feasible and the task has to take on a "restart" instead. The suggestion to pass in some parameter makes this in to something more like a state machine, where depending on state (initial vs resume) a different code path is taken. This is a fine approach but not one I think Taskflow should support/facilitate/promote explicitly. Having the concept/approach baked in to the standard interface would do just that. Instead, I wonder if having some limited amount of "task local" storage would allow support for this sort of use as well as other potential use cases.

I'm not positive I understand what "signal the flow via an external method" means, but if that means having the engine react to an external signal, I'm not sure that's something that needs to be built in to taskflow. Rather, I'd like to add additional states to Jobs, such that when a task is suspended, the Job enters an appropriate state (not sure what it should be called, let's say "suspended" for now), and Job processors/consumers/conductors can then skip over the "suspended" job until a separate service/process/thread (some sort of event handler) changes the Job state and allows the Job to be processed. The key thing is taskflow should ideally stay a library rather than an active service and provide application designers the tools/flexibility to do things they need.
----------