Arvados

Peter started work on this in #22706. I've moved the CWL-related commits from that branch and reworded them to refer to this ticket number instead.

22996-cwl-published-ports @ c5cece598033cd92a32c25ead8aa893a6ac00b82

22996-cwl-published-ports @ f34259e4bcc4855ce94dbabb9dfa5d1fbaa2fbaa - developer-run-tests: #4895

I have taken the branch that Tom extracted and rebased it on main. It still has Peter's original commits and I am happy with those review-wise. From there I have done some minor extension to support changes to published ports API since then and added documentation.

• All agreed upon points are implemented / addressed. Describe changes from pre-implementation design.
  • Yes
• Anything not implemented (discovered or discussed during work) has a follow-up story.
  • N/A
• Code is tested and passing, both automated and manual, what manual testing was done is described.
  • CWL tests pass. I have also manually run the attached CWL and it runs an nginx server. This will feed into the guide for #23051.
• Tested code incorporates recent main branch changes.
  • Yes
• New or changed UI/UX and has gotten feedback from stakeholders.
  • Peter decided the original spelling of everything except initialPath. I am signing off on all that spelling.
• Documentation has been updated.
  • Yes
• Behaves appropriately at the intended scale (describe intended scale).
  • No change in scale, just propagating a new API feature out to clients
• Considered backwards and forwards compatibility issues between client and server.
  • Like other CWL extensions, the new code detects whether the Arvados API is new enough to support the feature and raises an exception if not.
• Follows our coding standards and GUI style guidelines.
  • Yes

It might be worth mentioning in the description of access=="private" in the CWL docs that it can't just be any token.

CWL docs currently say

If "private", Arvados will require clients to provide an authorized arvados_api_token parameter to connect to this service port.

But per container docs,

If “private”, the client connecting to the container must provide an Arvados API for the user who submitted the container request(s) corresponding to the container.

(Even if "authorized" arguably makes the two statements consistent, I think it would be more helpful to be more explicit.)

Rest LGTM.