require OperationalCredentialsDelegate refactor

[msandstedt]

Problem

Related: #5055, #6656, #7859

The current OperationalCredentialsDelegate interface has a number of limitations that block integration into many designs. Some examples:

• some interfaces are still synchronous; all must be async
• end-to-end attestation from the certificate authority is not well-supported
• the single instance delegate with separate root / ICA / NOC getters implies a single root and ICA for the entire ecosystem
• the commissioning state machine is driven by the sdk; it needs to be driven by apps that call into the sdk
• we need a way to pass in session-specific context for each node to be commissioned
• the current design includes some non-spec-mandated behaviors, such as commissioners proposing fabric IDs and node IDs to signing infrastructure; such behaviors need to be moved out of the chip::controller::deviceCommissioner object and into apps

Proposed Solution

In meetings with stakeholders, it has become clear that the problems with the OpCreds delegate interface are actually a symptom of a more fundamental problem.  The chip::controller::DeviceCommissioner design is missing a necessary layer of abstraction.  Consider the DeviceComissioner object's internal states:

enum CommissioningStage : uint8_t
{
    kError,
    kSecurePairing,
    kArmFailsafe,
    // kConfigTime,  // NOT YET IMPLEMENTED
    // kConfigTimeZone,  // NOT YET IMPLEMENTED
    // kConfigDST,  // NOT YET IMPLEMENTED
    kConfigRegulatory,
    kCheckCertificates,
    kConfigACL,
    kNetworkSetup,
    kScanNetworks, // optional stage if network setup fails (not yet implemented)
    kNetworkEnable,
    kFindOperational,
    kSendComplete,
    kCleanup,
};

These shouldn't exist here in the first place. The sdk's chip::controller::DeviceCommissioner object is preempting what should be the role of the commissioner app proper.  Instead of driving its own state machine, we need the sdk to provide stateless commissioning methods that map to transactions in the spec's commissioning sequence.  These are the edges in the commissioning state machine, not the states themselves.

It seems then that the functionality provided by `chip::controller::DeviceCommissionert must be divided into two halves:

• one half should be a stateless collection of helpers to provide apps the means to drive a commissioning flow
• the other half is the remainder of stateful logic that in the DeviceCommissioner object; it is fine for in-tree examples to embrace this approach; it is not good that the sdk imposes this approach on any app that attempts to leverage existing code; this therefore needs to be separated and moved to a different location

[msandstedt]

@pan-apple , @tcarmelveilleux , @mspang , @bzbarsky-apple , @woody-apple , @ritikananda27 , @samadDotDev, @kianooshkarami

[msandstedt]

Despite additions and refinements, we do not believe the sdk commissioner implementation can currently meet our product needs. To this end, and per the proposed solution above, I have developed a prototype that would meet our needs. See the prototype here: https://github.com/msandstedt/connectedhomeip/tree/com-fsm.

Leveraging the recently added src/lib/support/StateMachine class, this defines commissioning states and transition events as object types, and allows app implementations to add and remove states and events as needed. Reordering is also readily achievable. And because states and events are types, not values, both can have an arbitrarily sophisticated interfaces. This keeps most transient state data out of any sort of long-lived top-level object, and so the peak memory footprint should be lower.

Core sdk commissioning states can be seen here:

https://github.com/msandstedt/connectedhomeip/blob/com-fsm/src/controller/CommissioningStates.h

An example application implementation can be seen here. This is minimally tied into chip-tool:

https://github.com/msandstedt/connectedhomeip/blob/com-fsm/src/controller/ExampleCommissioningStateMachine.h

I would welcome any feedback people might have.

[woody-apple]

@msandstedt What work remains here?

[msandstedt]

There are two things here. While originally the discussion started with the operational credentials delegate interface being insufficient, that now has been addressed.

The other thing that came up in discussions was general non-extensibility of the commissioner. I had proposed one solution to this. The AutoCommissioner is another.

I think at this point we are considering the current commissioner implementation to be acceptable, and therefore this issue can be closed.