As the subject says, this PR makes sure that on de-provisioning (fabric removal) we also clean up the transport from all sessions associated with the fabric which is being removed.
The PR will also remove all subscriptions associated with the removed sessions.
(Since it is now possible) the PR implements logic that would cause any exchanges waiting on recv or send of a session which is being removed to immediately bail out with "NoSession" rather than waiting until the recv/send timeout expires
This PR also fixes https://github.com/project-chip/rs-matter/issues/182, but that's because the fallback code-path where - in the absence of a valid session ID - we search (and potentially create) a session by fab-idx + peer node ID, is now (temporarily) commented out.
I think we should restore the fallback logic back to life once we know how exactly to find (or create) a session for reporting which is different from the original one.
For now, reporting only thru the original session is seemingly good enough. The peer node would anyway resubscribe if the session is over and it does not receive a subscription response within the provided timeout (which most of the time seems to be one minute).
recv
orsend
of a session which is being removed to immediately bail out with "NoSession" rather than waiting until therecv
/send
timeout expiresThis PR also fixes https://github.com/project-chip/rs-matter/issues/182, but that's because the fallback code-path where - in the absence of a valid session ID - we search (and potentially create) a session by fab-idx + peer node ID, is now (temporarily) commented out.
I think we should restore the fallback logic back to life once we know how exactly to find (or create) a session for reporting which is different from the original one.
For now, reporting only thru the original session is seemingly good enough. The peer node would anyway resubscribe if the session is over and it does not receive a subscription response within the provided timeout (which most of the time seems to be one minute).