Overhaul the Event system implementation to follow the structure of EventSetup

[makortel]

The rigidity of the Event system is starting show problems for the evolution of the framework. Some symptoms

• ExternalWork ability requires the developer to explicitly store the data to be passed from acquire() to produce() Add mechanism in ExternalWork to send data from acquire() to produce() cmssw#24186
• The mapping of BranchDescription to a corresponding ProductResolver type is complicated https://github.com/cms-sw/cmssw/blob/e5ac8e997d5565e91eea5eaa91884a2b17a0fde4/FWCore/Framework/src/Principal.cc#L150-L216
  • SwitchProducer required two concrete ProductResolvers and an intermediate base class
  • Transformer required a new ProductResolver type

The EventSetup system is much more flexible in this regard. At some point it would become cheaper to revamp the Event system to use the similar (same?) internals as the EventSetup system.

Related other issues

• Redesign in Principal, Resolver, TransitionInfo classes #34 / Redesign in Principal, Resolver, TransitionInfo classes cmssw#31457
• BranchDescription not properly handled in cases of merged files cmssw#47083

Plan

• Move construction of ProductResolvers elsewhere from the Principal constructors #1145
• Remove adding additional ProductResolvers at file boundaries #1150

[makortel]

This ability would be useful for multiprocessing across nodes as well (see https://indico.cern.ch/event/1480583/#19-update-on-cmssw-clientserve for what motivated this conclusion).

The idea would be to make the ProductResolvers to be the communication points across processes rather than the modules.

[makortel]

Points from brainstorming 2024-12-10

• Modules should set up ProductResolvers
• Would like to create Source-like things
• If we want to add "more fine-grained asynchronous splitting than 1 point between acquire() and produce()" with multiple production functions (as in ESProducers):
  • We'd need more automation in early deleting event data products (e.g. Improve early deletetion by making data product dependencies (via Ref, pointer, etc) to be declared by their EDProducer #424)
  • Avoiding ROOT dictionaries for transient data would help (Redesign the use of ROOT dictionaries for data product reflection #13)