commit 6c1cb331f7aae3d038b52da4071c31aa5a8c5ca2
author Marc Lepage <67919234+mlepage-google@users.noreply.github.com> Wed Feb 15 11:01:31 2023 -0500
committer GitHub <noreply@github.com> Wed Feb 15 11:01:31 2023 -0500
tree 6db2fc842571bdbf018529f62ad35f545fbc4134
parent ed7ff70ceab7ec50b819abc85d0f275d57172fbd

Add background event handling for CASE establish (#24099)

* Add background event handling for CASE establish

CASE session establishment has operations which are costly, such as
checking certificate chains. The handshake messages are processed in the
event thread, so while these operations occur, other events cannot be
processed. This delays responses, and can cause the event queue to fill
entirely, which is fatal.

This commit adds support for background event processing, and uses it to
process the most costly operations during CASESesssion::HandleSigma3.

- add platform support for background event processing:
  ScheduleBackgroundWork, RunBackgroundEventLoop, etc.
- add device config flags for enabling/disabling and configuration
- add implementation for FreeRTOS platform
- refactor some CASESession operations so they can be static, avoiding
  use of member variables
- break HandlSigma3 into 3 parts A/B/C:
  - HandleSigma3a (foreground, processes incoming message)
  - HandleSigma3b (background, performs most costly operations)
  - HandleSigma3c (foreground, sends status report)

This breakup of HandleSigma3 was done in a fairly straightforward manner
so it could be clearer, during review, that behaviour has not
substantially changed. A subsequent commit should clean it up further by
introducing helper code for managing the foreground/background work,
lifetime of work object, when to send status report and/or abort pending
establish, etc.

Also still to do is implementation for other platforms, and for other
messages in CASESession (e.g. Sigma2), and for other costly operations
(e.g. PASESession).

Currently, CASE session establishment is simplified:

- only one pairing session is active at a time
- it's always the same CASESession object in CASEServer
- the two classes are higly coupled (e.g. CASEServer relies upon
  CASESession aborting the pending establish if an error occurs)

Therefore, HandleSigma3b can rely upon the lifetime of the CASESession
object, use an additional state and sequence number to synchronize
work across foreground/background, and avoid use of member variables.
If and when CASE session establishment becomes more complex, assumptions
should be revisited.

TESTING

Testing was performed on M5Stack (ESP32) by commissioning using the
Google Home app on Android.

First, baseline behaviour with background events disabled:

- If no errors, commissioning succeeds as before
- If HandleSigma3a fails and sends a status report,
  pairing retries promptly and succeeds
- If HandleSigma3a fails and cannot send a status report,
  pairing retries after about a minute and succeeds
- If HandleSigma3c succeeds but cannot send a status report,
  pairing retries after about a minute and succeeds

Next, improved behaviour with background events enabled:

- If no errors, commissioning succeeds as before
- If HandleSigma3a fails and sends a status report,
  pairing retries promptly and succeeds
  - (this includes failure to schedule HandleSigma3b)
- If HandleSigma3b fails and sends a status report,
  pairing retries promptly and succeeds
- If HandleSigma3c fails and sends a status report,
  pairing retries promptly and succeeds
- If HandleSigma3c succeeds but cannot send a status report,
  pairing retries after about a minute and succeeds
- If HandleSigma3b is starved (scheduled but does not complete),
  after several minutes the failsafe timer fires, then Home app
  allows try again, which then succeeds
- If HandleSigma3b is delayed (completes late), the sequence number
  is unexpected, so no status report is sent, then
  after several minutes the failsafe timer fires, then Home app
  allows try again, which then succeeds

* Remove WIP code

* Address some comments from code review

* Remove cruft from testing.

* Remove some conditional compilation

* Remove some conditional compilation

* Move function back where it was

Had more related changes, but they're all removed, so remove this
change also.

* Add some documentation

Change error code also.

* Use platform new/delete

* Undo changes that are merely reordering

Cleanup can occur in a subsequent commit.

* Undo changes that are merely reordering

Cleanup can occur in a subsequent commit.

* Remove include file fix (C/C++)

* Add documentation to background processing API

* Use alternate fabrics table API

* Improve documentation

* Add assertion

* Undo some unrelated cleanup

* Update src/protocols/secure_channel/CASESession.cpp

Co-authored-by: Boris Zbarsky <bzbarsky@apple.com>

* Ensure root cert buf keeps span

* Restyled by whitespace

* Restyled by clang-format

* Add new functions to GenericPlatformManagerImpl

So all platforms build and work, even if they don't use the new feature.

* Attempt to fix build errors on some platforms

Apparently initializing structs with anonymous unions is challenging.

* Improving host test environment

This commit has a bunch of extra logging etc. to flush out any more
CI issues.

* Remove log statements and clean up

* Update fake PlatformManagerImpl

* Increase timeout on fake linux CI

* Redo changes to make tests work

Undo previous changes to test/app contexts, and go back to just fixing
the tests more surgically and contained.

Passes Linux host tests and Linux fake platform tests now.

* Undo SetSystemLayerForTesting

nRF/Zephyr tests don't like this not being cleaned up.
May fix Darwin too?

* Change fake linux tests timeout back to 15 mins

* Restyle

* Init/shutdown platform mgr in TestCASESession

Seems needed on Darwin.

---------

Co-authored-by: Boris Zbarsky <bzbarsky@apple.com>
Co-authored-by: Restyled.io <commits@restyled.io>