Replace floating-point seconds with integer milliseconds in timing config

[shegazyy]

…nfig

All 8 timing fields in new_lm_flatcfg.fbs are changed from double (seconds) to uint32 (milliseconds), eliminating the need for the secondsToMs() conversion helper and removing the floating-point representation from the binary format entirely.

Changes:

• new_lm_flatcfg.fbs: 8 timing fields changed from double to uint32
• flatbuffer_config_loader.hpp: kExpectedSchemaVersion bumped 1 → 2
• flatbuffer_type_converters.hpp/.cpp: removed secondsToMs() and kSecondsToMilliseconds; all 7 call sites simplified to direct assignment
• flatbuffer_type_converters_UT.cpp: removed 5 SecondsToMsTest cases; updated all FlatBuffer builder calls to pass millisecond integers
• flatbuffer_config_loader_UT.cpp: updated all builder calls likewise
• lifecycle_config.py (gen_config): added sec_to_ms() conversion for all 8 timing fields so the generated JSON matches the new uint32 schema
• launch_manager.schema.json: updated schema_version enum from [1] to [2]
• All 20 JSON config files: "schema_version": 1 → "schema_version": 2

Closes #345

[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.6.0) and connecting to it...
INFO: Invocation ID: 7c5915c2-c229-4f73-8ba7-862e1262ac8d
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: 
Analyzing: target //:license-check (1 packages loaded, 0 targets configured)
Analyzing: target //:license-check (1 packages loaded, 0 targets configured)

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

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

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

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

Analyzing: target //:license-check (152 packages loaded, 5304 targets configured)

Analyzing: target //:license-check (153 packages loaded, 8205 targets configured)

Analyzing: target //:license-check (164 packages loaded, 8271 targets configured)

Analyzing: target //:license-check (164 packages loaded, 8271 targets configured)

Analyzing: target //:license-check (164 packages loaded, 8271 targets configured)

Analyzing: target //:license-check (164 packages loaded, 8271 targets configured)

Analyzing: target //:license-check (167 packages loaded, 10159 targets configured)

Analyzing: target //:license-check (168 packages loaded, 10283 targets configured)

INFO: Analyzed target //:license-check (169 packages loaded, 10409 targets configured).
[13 / 16] JavaToolchainCompileClasses external/rules_java+/toolchains/platformclasspath_classes; 0s disk-cache, processwrapper-sandbox
[15 / 16] Building license.check.license_check.jar (); 0s disk-cache, multiplex-worker
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.963s, Critical Path: 2.55s
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

[NicolasFussberger]

could we change the names here also with _ms suffix? Then it also be obvious in the generated code that this is in ms

[NicolasFussberger]

We have the difficulty a bit that we are currently in transition.
The new_lm_flatcfg.fbs is the new flatbuffer schema that shall replace the legacy flatbuffer configs.
Though this is currently still only under a feature flag active. The regular build is still using the legacy configs.

My proposal for this PR would be:

• We keep the adaptation for the new config path
• We do not adapt the old config anymore as this is removed soon
• We leave the user-facing json schema unchanged for now, and adapt this once the feature flag is gone and the new config is in use. Then we'll change the user-facing json config from seconds to ms as well.
• This means the translation btw. seconds->ms is done in the lifecycle_config.py for now, as the user-facing json is still configured with seconds (unchanged) and the new flatbuffer schema expects milliseconds (changed).

I think this matches what you already did, only the user-facing json schema change would need to be reverted. As the user-facing json schema is anyway not changed here, I think we don't need to increase the schema version.

What do you think?

[NicolasFussberger]

The build with new config feature flag bazel build //score/... --config=x86_64-linux --//config:use_new_configuration=True is currently broken (not because of your changes, but because the compiler warnings are now enforced).

Could you apply this simple fix, to get your branch build successfully with new config flag active?

score/launch_manager/src/daemon/src/main.cpp:

         auto config_result = config_loader.load(config_path);
-        if (!config_result.has_value()) {
-            LM_LOG_FATAL() << "Failed to load config from: " << config_path;
+        if (!config_result.has_value())
+        {
+            LM_LOG_FATAL() << "Failed to load config from: " << std::string_view(config_path);
             return EXIT_FAILURE;
         }
 #endif

[NicolasFussberger]

Thanks for your contribution! Changes look good to me.

As explained in another comments, I'd only revert the schema version increase, as the json schema is not changed here.

Please take a look at the PR checks, there are some small things to fix to make them pass.