feat: add TimeDaemon CIT with pip hub infrastructure

[gordon9901]

This PR adds TimeDaemon component integration tests with pip hub infrastructure (part 1 of 3):

• Add three independent pip hubs for TimeDaemon, TimeSlave, and MIT test suites
• Add score_test_scenarios framework dependency with compatibility patch for score_baselibs 0.2.7
• Add TimeDaemon CIT covering daemon lifecycle, control flow, IPC, SVT, and verification pipeline
• Fix visibility for shm_ptp_engine and svt_handler to allow access from test scenarios

Part of #56

test QNX

[github-actions]

License Check Results

🚀 The license check job ran with the Bazel command:

bazel run //:license-check

Status: ⚠️ Needs Review

Click to expand output

[License Check Output]
Extracting Bazel installation...
Starting local Bazel server (8.6.0) and connecting to it...
INFO: Invocation ID: 2f5b7cd7-0e10-47f6-bbdd-e7a574e21f87
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
WARNING: For repository 'platforms', the root module requires module version platforms@1.0.0, but got platforms@1.1.0 in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Loading: 
Loading: 3 packages loaded
Analyzing: target //:license-check (4 packages loaded, 0 targets configured)
Analyzing: target //:license-check (4 packages loaded, 0 targets configured)

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

Analyzing: target //:license-check (110 packages loaded, 378 targets configured)

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

Analyzing: target //:license-check (160 packages loaded, 6249 targets configured)

Analyzing: target //:license-check (161 packages loaded, 8516 targets configured)

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

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

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

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

Analyzing: target //:license-check (176 packages loaded, 11429 targets configured)

INFO: Analyzed target //:license-check (177 packages loaded, 11555 targets configured).
[11 / 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
[12 / 16] JavaToolchainCompileClasses external/rules_java+/toolchains/platformclasspath_classes; 0s disk-cache, processwrapper-sandbox ... (2 actions running)
INFO: From Generating Dash formatted dependency file ...:
INFO: Successfully converted 2 packages from Cargo.lock to bazel-out/k8-fastbuild/bin/formatted.txt
[14 / 16] JavaToolchainCompileBootClasspath external/rules_java+/toolchains/platformclasspath.jar; 0s disk-cache, processwrapper-sandbox
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: 30.296s, Critical Path: 2.64s
INFO: 16 processes: 12 internal, 3 processwrapper-sandbox, 1 worker.
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>]

[github-actions]

The created documentation from the pull request is available at: docu-html

[BjoernAtBosch]

Sorry, I don't understand this: What is the benefit of using the combination of the pytest/testing_utils plus C++ code over using plain gtest/gmock? At the moment it looks to me making things more complicated and harder to understand.

Imho, for all the component internal testing, I would use gtest. That doesn't mean that everything tested with gtest is automatically a unit test (in the strict sense), it can be also some sort of integration tests - i.e. test which integrate multiple classes and test them together.

Then on the level of testing the whole component as a binary - TimeDaemon in this case - I'd use some pytests framework or ITF to stimulate and test the binary from "outside". And next step would be testing of multiple binaries "playing together".

[gordon9901]

Thanks, fair point. You're right that ptp_divider and the single-validator scenarios were duplicating gtest coverage with unnecessary indirection — I've removed them in the latest push.

The CIT layer now only keeps scenarios that wire together two or more production objects: verification.pipeline (PTP stub → verification machine), ipc.shm_roundtrip (publisher/receiver over shared memory), and daemon.lifecycle (full SvtHandler init/shutdown). Single-class behaviour stays with gtest under src/. Added a short README documenting the boundary.

The pytest + test_scenarios stack is the same SCORE-standard framework used for the upcoming module-integration and system-test layers (multi-binary, QEMU), so keeping it here gives one runner surface scaling up to those levels. Let me know if that still feels off.