Work around a bug in FastAPI (fastapi/fastapi#13175) that assigns the same operation id to both request methods GET and HEAD of the endpoint `/api/jobs/{job_id}/files` when using the `@router.api_route()` decorator with `methods=["GET", "HEAD"]` as keyword argument.

…T requests to `/api/jobs/{job_id}/files`

Pulsar formats the `path` and `job_key` parameters as query parameters when submitting POST requests to `/api/jobs/{job_id}/files`. However, many Galaxy tests format them as form parameters. The only way to keep the endpoint working as it should (as it worked before the migration to FastAPI) is to accept both query and form parameters.

… requests to `/api/jobs/{job_id}/files`

FastAPI will not use the parameter aliases of form parameters in the OpenAPI docs, but the name of their Python variables. Therefore, the API docs show `path_form` and `job_key_form`. Rename them so that the API docs show the correct parameter names.

…ndpoint)

This commit introduces the following differences in behavior:
- GET and HEAD requests to `/api/jobs/{job_id}/files` return HTTP status code 400 when the given path does not refer to a file or the input datasets for the job have been purged and 404 when the given path does not exist.
- PROPFIND requests to `/api/jobs/{job_id}/files` are answered with HTTP status code 501 (read motivation for this change below).
- POST requests to `/api/jobs/{job_id}/files` are answered with HTTP status code 400 when no file is provided.

The reason behind the code explicitly answering `PROPFIND` requests with status code 501 is an unfortunate interaction between the ARC remote job runner that is under development, the behavior of legacy API endpoints and how they are integrated within the FastAPI app.

The ARC remote job runner (which will be implemented as `lib.galaxy.jobs.runners.pulsar.PulsarARCJobRunner`) expects this endpoint to return HTTP codes other than 404 when `PROPFIND` requests are issued. They are not part of the HTTP spec, but they are used in the WebDAV protocol. The correct answer to such requests is likely 501 (not implemented).

FastAPI returns HTTP 405 (method not allowed) for `PROPFIND`, which maybe is not fully correct but tolerable because it is one less quirk to maintain.

However, because of the way legacy WSGI endpoints are injected into the FastAPI app (using `app.mount("/", wsgi_handler)`), the built-in support for returning HTTP 405 for `PROPFIND` breaks, because such requests are passed to the `wsgi_handler` sub-application. This means that the endpoint still needs to include some code to handle this behavior.

When ALL routes have been migrated to ASGI (no WSGI handler sub-application needed anymore), some lines of code can be removed, they are labeled using comments.

…iles`

This path already supports GET, HEAD and POST requests; add support for PUT requests. There is a significant difference in behavior between POST and PUT requests:
- POST requests take `path` and `job_key` both as query parameters or as body parameters belonging to a multipart request. PUT requests take them only as query parameters (just like GET and HEAD).
- POST requests submit a file as one of the fields of the multipart request, whereas the submitted file is the whole body of the request for PUT requests.
- POST requests can append to the `tool_stdout` and `tool_stderr`, PUT requests can only create new files or overwrite whole files.
- POST requests support resumable uploads but PUT requests do not.
- POST requests take the form parameters `__file_path` (path of a file uploaded via the nginx upload module) and `__file` but PUT requests do not.

Add method to inject kwargs into the `build_client_manager()` function.

Rewrite the method `PulsarARCJobRunner.queue_job()` so that it:
- Obtains the ARC endpoint URL either from the user's preferences or the destination parameters.
- Requests an OIDC access token for the user running the job.
- Decides which OIDC provider to get the token from if multiple are available, based on the user's preferences and the destination parameters.

To let users configure their own settings, admins have to set the destination parameter "arc_user_preferences_key". Galaxy will then read the options "arc_url" and "arc_oidc_provider" under that key from the user extra preferences. Both are optional; if the user does not configure a value, the destination default will be used. If no destination default exists and the user account is associated with exactly one OIDC provider, then Galaxy will use that provider.

These tests verify that the ARC endpoint URL and OIDC provider selection logic works correctly when queuing jobs. They
do not test actual job execution, as that is covered by Pulsar's own tests.