Be able to take a workflow by URL, not workflow descriptor

[geoffjentry]

The cromwell API currently only allows users to submit the actual workflow file when they'd like to run a workflow. Also allow for a user to submit the URL pointing to the workflow file, which will then be consumed by Cromwell.

Edit: While the end goal is to not need a zip bundle for dependencies (as they can now be worked out via relative paths - cc @cjllanwarne ) -- that work is part of 3868.

NB: TBD (@ruchim ?) what should we do with file:// URLs? Perhaps a config option defaulting to off?

[geoffjentry]

Make sure that @cjllanwarne knows if you pick this up

[cjllanwarne]

• The "no zip bundle" set of import resolvers is probably the right one to use when trying to "resolve" the original file from String (unless a dependencies zip is also supplied?).
  • Side comment: should we therefore make the set of import resolvers to use Cromwell's responsibility? (right now every language factory comes up with its own set 😱)
• We should try end up as similar to the WES equivalent as possible when adding this
  • To find out: is this just submit with workflowRoot + no workflowSource, or is it a separate endpoint?

[ruchim]

@geoffjentry -- Yes, sounds good as a first pass to not support file://. If it's a local file, it should be submitted as expected under workflowSource

@cjllanwarne -- I believe its only the /submit or /workflow-runs post endpoint (in WES terminology) that uses the workflowSource & workflowRoot equivalents.

[ruchim]

@cjllanwarne I changed the original content of this issue to separate out the work planned towards a CUI milestone. Let me know if something looks wrong.