For an architecture diagram that explains the logic behind the DagsterFlyteSdkWorflow class please review.
This diff implements a first pass of the class shaded in blue that inherits from a flytekit workflow. I have done this in an object oriented fashion, but provided a function that encapsulates everything. Please let me know if people would prefer something less object oriented here.
Currently, this iteration bypasses Flyte's type system as well as their Input + Output promises. To that end, this will only work when all of the input and output config is provided adequately via Dagster. However, I believe so long as we do this, then Flyte can run arbitrary configurations of our DAGs.
In a future diff we can map the input/output promises as well as types. The flyte team is willing to offer some guidance on working with their type system.