Move IM standalone test run on a single event loop

[yufengwangca]

Problem

What is being fixed? Examples:

• This PR is to fix the remaining race issues happens in IM test by running everything within a single event loop.

• Currently, Platform Layer provides both API RunEventLoop to run Matter on the app main thread and StartEventLoopTask/StopEventLoopTask to run Matter on a separate thread. For internal testing, we plan to make all test apps single threaded to prevent any race issue occurs.

• Fixes Move IM standalone test run inside chip thread. #7939

Change overview

Move IM standalone test run on a single event loop

Testing

How was this tested? (at least one bullet point required)
Setting up cirque environment
git submodule update --init
./scripts/tests/cirque_tests.sh bootstrap

Run IM test for 10 times and confirmed no race issue occurs
./scripts/tests/cirque_tests.sh run_test InteractionModelTest

[yunhanw-google]

thanks

[bzbarsky-apple]

This does not look right to me. This will call:

    chip::DeviceLayer::PlatformMgr().StopEventLoopTask();
    chip::DeviceLayer::PlatformMgr().Shutdown();

from inside RunEventLoop. The documentation for StopEventLoopTask says that when used this way it does not guarantee that all work is done until RunEventLoop returns. So it's not safe to call PlatformMgr().Shutdown until that point, as the documentation for RunEventLoop explicitly says.

In fact, it's not safe to shut down the IM engine until that point either.

[bzbarsky-apple]

It looks like #8100 had similar problems, in addition to possibly calling StopEventLoopTask when there is no event loop running, which is also not ok.

[yufengwangca]

I updated the logic to only call StopEventLoopTask to trigger RunEventLoop to exit after all work item processing is stopped. And do platform shutdown only after the RunEventLoop returns.

[bzbarsky-apple]

So in this new setup each test will definitely run for gMessageIntervalSeconds instead of completing when the response is received, right? Is that intended?

[yufengwangca]

Yes, it is intended. We always start new test after interval gMessageIntervalSeconds

[bzbarsky-apple]

Alright. Seems like it will make the test run much slower, but maybe that's ok....

[bzbarsky-apple]

This does not make sense to me. This is after RunEventLoop has returned, so what does it even mean to call this function here?

[yufengwangca]

Acked, we don't need to explicitly stop event loop after RunEventLoop returned

[github-actions]

Size increase report for "esp32-example-build" from 046f46a

File	Section	File	VM
chip-lock-app.elf	.flash.text	-64	-64
chip-temperature-measurement-app.elf	.flash.text	60	60

Full report output

BLOAT REPORT

Files found only in the build output:
    report.csv

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

sections,vmsize,filesize

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

sections,vmsize,filesize

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

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

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

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

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

sections,vmsize,filesize

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

sections,vmsize,filesize