[controller] reset Device state for usage in accessories

[gjc13]

Problem

The controller::Device class is currently tightly assuming the device state and forcing a commssion flow starting from PASE.

Change overview

Reset the state in OperationalCertProvisioned so that we can call this function to start from CASE.

Testing

How was this tested?

• CI build and unit tests.

[gjc13]

@msandstedt The change follows our discussion in #9103. Though it's kind of hack it unblocks us.

@mspang @andy31415 PTAL.

[gjc13]

I had offline discussion with Tennessee and here is his comments:

I think you misunderstood Michael's comment
My point in the original comment is that reimplementing Device with subset functionality for each example is problematic
Separate from that I agree with Michael's points but I would say that just hacking the PASE state machine is not quite right. I agree with Michael that changes are few. Since I do not have much time this week, I suggest you work with Spang and Michael on resolution. I think the interaction peer change also was helpful, and overall, we will need to incrementally "separate" device/controller but we have to unblock device to device. I just want to make sure we dont make too many "compromise" changes that make the final solution hard to maintain (that is, as hard or harder to maintain than the problematic code we have now)

Personally I believe the delegate class #9103 is not an elegant solution.
The correct way out is to remove Device class from our controller generated code and use InteractionModelEngine as the only entrypoint to send ZCL or BDX messages. We'll add another class to manage the pairing process and setup the symmetric credentials.

This approach requires rewriting a large amount of code. As an unblocker, this hack looks quite acceptable compared to #9103. If we are using a temporary solution anyway, I'll prefer a smaller change.

[tcarmelveilleux]

Personally I believe the delegate class #9103 is not an elegant solution.
The correct way out is to remove Device class from our controller generated code and use InteractionModelEngine as the only entrypoint to send ZCL or BDX messages. We'll add another class to manage the pairing process and setup the symmetric credentials.

InteractionModelEngine is for the IM, which is a layer above Message Layer. BDX is a protocol handler that does not relate at all to IM. I disagree that InteractionModelEngine should be the entrypoint for everything.

[woody-apple]

While a 1 line change, what test failed? What is this fixing? What new test is added to confirm that this doesn't regress?

[gjc13]

While a 1 line change, what test failed? What is this fixing? What new test is added to confirm that this doesn't regress?

Unit test added. It's testing calling EstablishConnectivity after manually calling OperationalCertProvisioned. We'd expect a CASE session to be setup in this case. Before the change it will report ERROR_INCORRECT_STATE.

[github-actions]

Size increase report for "esp32-example-build" from 92309bc

File	Section	File	VM
chip-shell.elf	.flash.text	48	48
chip-ipv6only-app.elf	.flash.text	172	172
chip-lock-app.elf	.flash.text	64	64

Full report output

BLOAT REPORT

Files found only in the build output:
    report.csv

Comparing ./master_artifact/chip-temperature-measurement-app.elf and ./pull_artifact/chip-temperature-measurement-app.elf:

sections,vmsize,filesize

Comparing ./master_artifact/chip-persistent-storage.elf and ./pull_artifact/chip-persistent-storage.elf:

sections,vmsize,filesize

Comparing ./master_artifact/chip-shell.elf and ./pull_artifact/chip-shell.elf:

sections,vmsize,filesize
.flash.text,48,48
[Unmapped],0,-48

Comparing ./master_artifact/chip-pigweed-app.elf and ./pull_artifact/chip-pigweed-app.elf:

sections,vmsize,filesize

Comparing ./master_artifact/chip-bridge-app.elf and ./pull_artifact/chip-bridge-app.elf:

sections,vmsize,filesize

Comparing ./master_artifact/chip-ipv6only-app.elf and ./pull_artifact/chip-ipv6only-app.elf:

sections,vmsize,filesize
[Unmapped],0,3924
.flash.text,172,172

Comparing ./master_artifact/chip-all-clusters-app.elf and ./pull_artifact/chip-all-clusters-app.elf:

sections,vmsize,filesize

Comparing ./master_artifact/chip-lock-app.elf and ./pull_artifact/chip-lock-app.elf:

sections,vmsize,filesize
.flash.text,64,64
.debug_loc,0,4
.xt.lit._ZNK4chip4SpanIhE7SubSpanEjj,0,-8
.xt.prop._ZNK4chip4SpanIhE7SubSpanEjj,0,-12
[Unmapped],0,-64