Implement new control API

[danth]

This pull request adapts the launch manager (and tests) to use the new control API based on mw::com, and removes the old API.

Fixes #481.

[github-actions]

License Check Results

🚀 The license check job ran with the Bazel command:

bazel run --lockfile_mode=error //:license-check

Status: ⚠️ Needs Review

Click to expand output

[License Check Output]
Extracting Bazel installation...
Starting local Bazel server (8.7.0) and connecting to it...
INFO: Invocation ID: 888f0780-f607-43de-9fe8-7fb3cd200f21
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Loading: 
Loading: 0 packages loaded
Loading: 0 packages loaded
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Analyzing: target //:license-check (1 packages loaded, 0 targets configured)
Analyzing: target //:license-check (1 packages loaded, 0 targets configured)

Analyzing: target //:license-check (51 packages loaded, 10 targets configured)

Analyzing: target //:license-check (88 packages loaded, 10 targets configured)

Analyzing: target //:license-check (144 packages loaded, 737 targets configured)

Analyzing: target //:license-check (156 packages loaded, 4383 targets configured)

Analyzing: target //:license-check (158 packages loaded, 8562 targets configured)

Analyzing: target //:license-check (163 packages loaded, 9368 targets configured)

Analyzing: target //:license-check (169 packages loaded, 9541 targets configured)

Analyzing: target //:license-check (172 packages loaded, 11426 targets configured)

INFO: Analyzed target //:license-check (173 packages loaded, 11555 targets configured).
[12 / 16] Creating runfiles tree bazel-out/k8-opt-exec-ST-d57f47055a04/bin/external/score_tooling+/dash/tool/formatters/dash_format_converter.runfiles [for tool]; 0s local ... (2 actions, 1 running)
INFO: Found 1 target...
Target //:license.check.license_check up-to-date:
  bazel-bin/license.check.license_check
  bazel-bin/license.check.license_check.jar
INFO: Elapsed time: 25.810s, Critical Path: 0.69s
INFO: 16 processes: 4 disk cache hit, 12 internal.
INFO: Build completed successfully, 16 total actions
INFO: Running command line: bazel-bin/license.check.license_check ./formatted.txt <args omitted>
usage: org.eclipse.dash.licenses.cli.Main [-batch <int>] [-cd <url>]
       [-confidence <int>] [-ef <url>] [-excludeSources <sources>] [-help] [-lic
       <url>] [-project <shortname>] [-repo <url>] [-review] [-summary <file>]
       [-timeout <seconds>] [-token <token>]

[NicolasFussberger]

I would recommend to eventually move all the interaction handling with lmcontrol service and all the mw::com parts to a separate class and create an interface for the ProcessGroupManager class.

In case we want to exchange the underlying IPC implementation at some point it will be good if this is cleanly isolated in the code and e.g. the ProcessGroupManager does not need to be changed.

[NicolasFussberger]

I think all the code in Graph should only run on main thread to avoid the complexity of multi threaded code there.
One idea would be to post an event in the event queue when a request arrives so it can be processed on the main thread.
Then the result can be provided back to some "control" class that implements the mw::com communication

[hskang-amelia]

Hi @danth, nice to see the daemon side of ActivationResult publishing land.

One thing I noticed while reading through: RunTargetActivationSource::kRecoveryAction doesn't seem to be set anywhere. Graph::finalizeTransitionSuccess() only branches on is_initial_state_transition_, so a transition triggered by ProcessGroupManager::processGroupHandler()'s recovery path (pg.startTransition(recovery_state.pg_state_name_)) would currently report as kStateManagerRequest, even though no State Manager actually requested it.

Was this intentional for this pass (e.g. deferred to a follow-up), or is it worth threading a "recovery-triggered" signal from that call site into Graph before this merges — maybe a dedicated entry point similar to startInitialTransition()? Happy to help if useful.

[danth]

Was this intentional for this pass

Yes, I am still working on this. It will be implemented before the PR is marked as ready. :))