✨ QDMI devices should communicate required/offered forms of authentication

[marcelwa]

Problem Statement

#1355 introduces support for QDMI authentication via FoMaC. However, currently, users must be aware of the forms of authentication provided or required by a device. If they provide unsupported information, it merely triggers a logging event. For example, if they attempt to authenticate via user and password, whereas the device expects a token.

Proposed Solution

We need a mechanism that allows QDMI devices to communicate the forms of authentication they require/offer, similar to their supported program formats for job submission.

[burgholzer]

Just a couple of thoughts on this:
It is not quite true that the current devices do not support authentication. It's just that they don't need any authentication.
I would argue this is entirely valid for a QDMI device.
They all properly report that they do not support setting the respective parameter and session initialization succeeds as expected.

Maybe we need a way in QDMI to make this communication a little clearer.
A device would somehow have to communicate which authentication options it offers/needs.
This could be represented as a list of tuples of QDMI_DEVICE_SESSION_PARAMETER, where each entry in the list would be a valid way to authenticate with the device, e.g. via TOKEN or (USERNAME and PASSWORD).

This still does not quite solve the problem how a client would specify this for every available device and how to deal with BASEURL, but that's a topic for different issues.

@ystade: your input would be appreciated here

[marcelwa]

After our discussion yesterday, I agree that the current behavior is correct, albeit incomplete. We indeed would need functionality to ask a device what kind of authentication it supports. I'll update the issue accordingly.