New logic for establishing client connections

[lauckhart]

Most of this will be difficult to separate into separate commits so will likely need a "big bang" merge. And is maybe best considered "unreviewable" 🙄.

In addition to inevitable bugs this commit does not address legacy codepaths and thus leaves a large amount of deprecated code in place.

Overview:

• Adds PeerConnection function that performs Peer (re-)connection. This implements new connection logic we've discussed and isolates relevant state to a single closure.

• Other relevant bits include Peer.connect() and PeerExchangeProvider.

• Numerous changes to existing @matter/protocol components in support of above. I tried to keep these changes minimal but the diffs end up pretty horrendous... Mostly this deals with new options

• Adds additional information to PeerDescriptor, improves logic for reacting to descriptor changes, and now uses a partial descriptor to add/configure peers

• Adds optional access to Interactable and NodeProtocol via Peer class. This makes generic access to Peer features (e.g. reading Basic Information attributes) from @node/protocol more straightforward

• Improves ActionContext and constituent interfaces to make them more useful in a client context. For example you can now do e.g. toggle(undefined, { abort }) to make an invoke abortable

• Adds NetworkProfiles to manage semaphores associated with network access, identified by a string name

• Adds configurability to MRP handling to support new connection logic (namely, maximum backoff time and maximum number of retries)

• Moves some logic generic logic from @matter/node to @matter/protocol

• Changes lifecycle management of some dependencies of @matter/node to align them with the ServerNode instead of ServerNetworkRuntime

• Various other updates to @matter/node involve movement to @matter/protocol code paths, but there are also various general improvements to issues I encountered along the way

• Adds PeerTimingParameters to control new connection logic

• Makes more operations abortable

• Improves PeerAddress interning and ClientNode#peerAddress management

• Considerable rework of network error handling to improve naming and consistency

[Apollon77]

can we get some kinda of network info somehow into the log also at least on level of exchange creation or logging ... would potentially be easier for debugging

[lauckhart]

You mean specifically relating to semaphore slots held or something more general?

For semaphore specifically dedicated messages seem noisy but maybe we could log "slow acquisition" similar to how we handle transactions