Workflow init

[dandavison]

Closes #600

This PR makes it possible to define a workflow class __init__ method that will receive the workflow input positional args (i.e. the same workflow input args that are passed to the @workflow.run method). One way in which this is useful is that it allows the workflow to initialize itself in a way that uses the workflow input but is guaranteed to have occurred before any signal or update handler runs (at the start of a workflow execution, these handlers can start to execute before the main @workflow.run method).

In order to opt in to the new functionality, you must define the __init__ method so that its parameters exactly match those of the @workflow.run method. And your @workflow.run method parameters must be defined in a way that requires arguments (so you can't use e.g. def my_run(self, *args) with this feature).

The parameter names need not be the same, but in all other respects the two parameter lists must be identical:

• the two parameter lists must be the same length
• parameters in corresponding positions must be the same "kind". In practice this means that if your signatures employ the * or / syntax, then you must use that syntax in the same way in each signature.
• if default values are present on keyword args then the defaults must be the same
• if type annotations are present on a parameter in one then the same type annotation must be present on the corresponding parameter on the other. These annotations must be identical; there is no notion of subtyping. So for example if one has list[str] then list is not acceptable on the other.

Backwards compatibility

The implementation is based on assessing whether the workflow class could be instantiated as cls(), without arguments. If so, then we do that. This means that behavior will be unchanged for all existing Python workflow definitions that work today: for such code there should be no new exceptions at import time, or at run-time, and the change should not break replay of existing workflows.

It's possible that a Python workflow definition that does not work today because it demands extra arguments that are not supplied, finds itself suddenly working because it is given workflow arguments.

It's more likely however that such a workflow definition finds that the error is reported earlier -- at import time, rather than at workflow run-time.

How this was tested

• PR has several unit tests and two integration tests
• The samples repo tests pass against this branch

[dandavison]

Superseded by #645. Closing this PR as the next iteration's implementation is very different and most of the description and discussion in this PR does not apply.