Store process-wide architecture information in "event provenance"

[makortel]

See cms-sw/cmssw#30044. The "event provenance" should be interpreted widely along "metadata available at Event transition functions".

Possibly depends on ProcessBlock

Progress being tracked in https://github.com/makortel/framework/milestone/22 (opened milestone as the development started to require many tasks)

Needs first

• Create a new Service to collect the architecture information from CPU Service and CUDAService #361
• Change JobReport and CondorStatusService to take the information from the ResourceInformationService #362 (not strictly needed though)

Plan

• Extend reduced history check to fake the release version #1100
• Demonstrate in streamer format that changing full ProcessConfiguration in a way that keeps reduced ProcessConfiguration the same does not cause new lumi or new run
• Add compute node architecture information to ProcessConfiguration
• Consider making reduced ProcessConfiguration its own type (maybe descope from this activity)

Canceled tasks

• Look if using special streamer file merging mechanism would allow using ProcessBlock as the storage after all #409
• Per-module information tracking spinned off to Store information on used compute resources per module #1099

[makortel]

cms-sw/cmssw#35879 shows a real use case for downstream consumers wanting to know details on how data product as produced.

In case of SwitchProducer, the information is in principle already in the event provenance, but would require knowing the exact C++ types of the possible EDProducers of a data product. In general one would also have to traverse the chain of the EDProducers because the offloaded EDProducer was not necessarily the one that the consuming EDModule consumed.

Knowing at Process level whether a Process had "offloading" enabled (today via SwitchProducer, in the near future likely in some other way) would give an easy handle for consumers like in cms-sw/cmssw#35879 to have enough knowledge on how the data products were produced.

[makortel]

Moved the per-module "architecture provenance tracking" to a separate #1099, and focus on process-wide tracking here, as that is needed in a timescale of 2 months.

[makortel]

Idea from a brainstorming on November 25, 2024

• Repurpose ProcessConfiguration::passId_ to contain whatever hw information we want
  • passId_ needs to be cleared in reduce()
  • StreamSerializer::serializeEvent() stores the full processHistory() from EventForOutput to SendEvent
  • StreamerInputSource::deserializeEventCommon() should really use the reduced ProcessHistoryID for the comparisons for new lumi or run
• To improve testing of reduced process history
  • Existing test in IOPool/Input/test/TestPoolInput.sh, but relies on old test files
  • Could fake the release version by passing in an untracked parameter via top-level PSet to ScheduleItems::initMisc()