Asynchronous and contextual node types via build contexts #66
Description
Imagine a node type that dispatches to another function whose definition lies in a database. We won't know what the inputs/outputs of that node are until we access the database. Furthermore the function might belong to a specific user of the database -- then we need authentication, conditioned on the context, to access it.
Thus, this is an example of asynchronous and contextual node typing, and we currently don't support it.
To actually support it we would need to turn input_type, output_type, etc. into functions that take in a build context. This would be a new concept separate from our current Context class, which is an execution context.
- a build context represents read-only resources that are available when figuring out a workflow's types
- an execution context represents read/write resources that are available during workflow execution
We have already been using the execution context to derive things like display name at build time. This created awkwardness around the object having two modes (e.g., execution-related resources have to be optional to avoid creating them when deriving display names). This issue will be addressed by moving display name, input type, and output type into build context.
Moreover... further down the line we have the issue of multi-tenancy with different users having different sets of Value types. This would require access to a ValueRegistry which would also need to be passed in...