Evaluate what happens if Darwin framework shuts down while an invoke/read/write is pending

[bzbarsky-apple]

Problem

Not clear how to handle Darwin framework shutdown while there are outstanding reads/writes/invokes. Right now it has a high chance of crashing...

Proposed Solution

Figure out what we can do. Perhaps similarly to #21198 all the interactions we issue via a controller should shut down when that controller shuts down.

[bzbarsky-apple]

@jtung-apple

[mrjerryjohns]

I think I sense where the solution here is headed, and I don't think we should be leaking into the SDK a need to more closely track active client-side objects when in fact, the right solution there is a stronger ownership model where applications are holding strong references to the requisite client side objects.

#21198 is only possible because we happen to track the list of active ReadClients for the purposes of routing unsolicited reports to the right instance, and that was exploited to also permit this shutdown model.

For most active client objects where their lifetime is synonymous with that of an exchange, presumably those will get torn down due to the closure of the underlying exchange. So if we can ensure to close all active exchanges, that should take care of invokes and writes right?

[bzbarsky-apple]

Closing all active exchanges associated with the controller might be enough. Need to check what actually happens in terms of callbacks in that happens.

But just to be clear, I'm not talking about doing this in the SDK. I'm talking about doing this in Matter.framework, which could track all the client objects it creates (since it creates them all, directly or indirectly) and in fact just destroy them as needed. It might need to stop using the *Interaction APIs to do this, of course...

[woody-apple]

Darwin Issue Review: We believe the behavior is correct now, closing.

[bzbarsky-apple]

In particular, chip::DeviceController shutdown expires the SecureSessions for its fabric and any PASE SecureSessions it created (the former after #15816 and the latter after #22282), which will immediately time out any pending write/read/invoke.