Enhance CASE (case.rs) with support for session negotiation initiation

[mstallmo]

This issue originates from the reply by @ivmarkov on #368. To quote the original comment:

Currently, Case only supports the use-case where another peer (say, the controller, but not only) initiates a CASE negotiation. I.e. it expects messages CASE-Sigma1 and CASE-Sigma3 and answers with CASE-Sigma2 and ACK to each of these.

We should also support the other way around, where rs-matter can initiate with CASE-Sigma1 and ongoing.
This is beneficial not just for the controller use case, but also for the device use case, when the device needs to actively initiate an exchange over a new session because of pending reporting over a subscription, where the subscription might no longer have a valid session in the sessions' manager.

Note that the transport layer itself (Exchange) is already prepared for initiating new exchanges (additionally to - and obviously - accepting new exchanges from another peer).

[ivmarkov]

@mstallmo Thanks for opening these.

FYI: Support for the Initiator side of PASE & CASE should be much easier to implement once #367 is reviewed and merged. I'm in the final stages of it already (just passed all Chip Tool Integration tests we have enabled on my PC with the rustcrypto backend; MbedTLS and OpenSSL to follow shortly).

[mstallmo]

@ivmarkov thanks for the info! I'll wait until #367 is merged to start in on the initiator for PASE and CASE.

I've started in on the implementation for mDNS querying with the various supported backends so that will be my focus for the time being. Hopefully by the time I'm done with that Crypto Traits are merged!

[ivmarkov]

@ivmarkov thanks for the info! I'll wait until #367 is merged to start in on the initiator for PASE and CASE.

I've started in on the implementation for mDNS querying with the various supported backends so that will be my focus for the time being. Hopefully by the time I'm done with that Crypto Traits are merged!

Np. Keep in mind, mDNS query might actually be trickier than the CASE and PASE tasks, as strange as it sounds. At least for the built-in mDNS, but possibly for the others too.

For example:

• Do you plan to support a query cache? (Because responses might arrive late)
• Or do you imagine just firing a query, then a timeout (say, a few hundred of millis) and whoever has responded is considered...

Might be interesting to see how the C++ SDK does it.