chip-tool can end up cleaning up interaction model objects on the wrong thread.

[bzbarsky-apple]

Problem

Steps to reproduce:

1. Build chip-tool and all-clusters-app.
2. In terminal 1, run all-clusters-app.
3. In terminal 2, run chip-tool interactive start
4. At chip-tool prompt run pairing code 17 749701123365521327694
5. At chip-tool prompt run basic subscribe data-model-revision 1 100 17 0
6. Kill all-clusters-app.
7. At chip-tool prompt run basic subscribe data-model-revision 1 100 17 0 --timeout 3

We fail threading assertions:

[1659545395124] [27950:4732727] CHIP: [DL] Chip stack locking error at '../../../examples/chip-tool/third_party/connectedhomeip/src/transport/Session.h:66'. Code is unsafe/racy

The issue is that that command instance has live a ReadClient from the first command execution that is still figuring out that its subscription is gone and hence has not called OnDone or anything.

When the second command times out, we land in CHIPCommand::Run, have deferCleanup false (because DeferInteractiveCleanup() returned false, because mSubscriptionEstablished was false in the second subscribe command), call Cleanup(), this destroys the ReadClients and now we are running IM code on the wrong thread and everything will be bad.

Proposed Solution

Need to figure out how to do this cleanup properly.