Project dependencies : use-cases

MR !2924 (closed) and issue Moore#372 (closed) triggered discussions on how to best organise project dependencies, summarised in @pkoppenb's talk at LHCb week. Presently the framework for doing combination of particles is duplicated between Moore and DaVinci do DaVinci can do combinatorics. This is not desirable, but was done to allow DPA to get started with developments. Now the question is how to make sure DaVinci can access this machinery. Options outlined in the talks are

1. Move common particles (and more) to Rec !2924 (closed)
2. Have DaVinci depend on Moore
3. Have Moore depend on DaVinci (actually does not solve much)
4. Link Moore and DaVinci by run-time dependency

Below we list the use cases we have to support in the next 10 years and which could have impact on the above

1. Users should be able to analyse the data of year N using the software of year N in order to get the exact same functors as were used in the trigger
   1. Also users should be able to analyse the data of year N using the software of year M (>N) in order to get the exact same functors as were used in the sprucing
2. Users should be able to analyse the data of year N but using the latest software to profit from new developments. Typically flavour tagging or jet/particle flow algorithms come to mind.

Feel free to add use-cases above.

During the meeting people expressed the opinion that having all configuration in one place helped development. Option 2 is favoured for this. The worry is that this forces to build DaVinci versions for each year of data taking, causing a large number of branches to be maintained.

For reference - related to DPA's task https://gitlab.cern.ch/lhcb-dpa/project/-/issues/62 and https://gitlab.cern.ch/lhcb-dpa/project/-/issues/180.

cc @gligorov @graven @sstahl @cburr @erodrigu @cattanem @clemenci @chasse @jonrob @nskidmor @adavis @raaij