remote_cred_cb: More input, more output

[chrysn]

The way aiocoap currently uses remote_cred_cb has become a monster:

resp = self.responders.create_responder(
        lambda id_cred_peer: self._get_peer_cred(
            # These we have to provide through a curried function
            # -- without those, it'd be hard to find the right key
            # if the same key identifiers are used for
            # obviously-different keys.
            peer_is_static,
            m1.cipher_suites,
            # Only this py-edhoc thinks is relevant.
            id_cred_peer,
            # This is kind of a second return value -- not only do
            # we need to pass the found key material out to EDHOC,
            # but also tell aiocoap which permissions are
            # associated with this.
            credential_identifier_cb,
            ),
        ...
        )
credential_identifier_cb = lambda identifier: setattr(resp, "application_identifer", identifier)

This is because at the time where I process the peer's cred_id, I not only need more information I'm currying in here (because someone could use the same compact key ID with different keys in different cipher suites / methods), but I also need to get the information about the selected key out again (in particular, when an OSCORE context is created, that information will be used to decide what the authenticated client is authorized to do).

One more piece of information that may need to go out of there is the list of supported cipher suites (but I'm not sure there yet).

I don't have a concrete proposal yet, but maybe we can gather some already here.

Kneejerk reactions without proper vettig are:

• Pass suite and staticness in to the remote_cred_cb.
• Alternative, pass the responder itself to the remote_cred_cb, so the key finding function can ask whatever it needs.
• Allow returning a third item (after the cred and the public key) that'll be stored in an attribute of the responder (like the dubious setattr lambda does here).