Pass std::any to dd4hep condition storage, to allow better type checking on LHCb side

Instead of passing the actual type to dd4hep when creating derived conditions, use std::any instead to provide better type safety checks than dd4hep itself can provide, on the LHCb side, when reading the conditions back. Implementation mirrors that used elsewhere in the Functional framework, where it is used to store arbitrary data in the TES.

Currently draft, as I have not finished all checks, but it works with at least the RICH tests in LHCb and Rec. However its still possible there are some corner cases I have not yet covered, in the other sub-systems.

Created to try and perhaps provide better diagnostic information for issues such as Rec#345 (closed)

FYI @sponce @bcouturi

mentioned in issue Rec#345 (closed)

added dd4hep label

added lhcb-dd4hep label

added RTA label

Just to note, the changes here will likely allow me to revert the changes I made in !3584 (merged) where I add a handle to side step dd4hep issues with memory alignment, as the std::any wrapping now performs that task.

mentioned in merge request !3544 (merged)

• [2022-06-03 00:04] Automatic merge failed in [lhcb-dd4hep#1148](https://lhcb-nightlies.web.cern.ch/nightly/lhcb-dd4hep/1148/LHCb/checkout
• [2022-06-04 00:05] Automatic merge failed in [lhcb-dd4hep#1149](https://lhcb-nightlies.web.cern.ch/nightly/lhcb-dd4hep/1149/LHCb/checkout
• [2022-06-05 00:03] Automatic merge failed in [lhcb-dd4hep#1150](https://lhcb-nightlies.web.cern.ch/nightly/lhcb-dd4hep/1150/LHCb/checkout
• [2022-06-06 00:04] Automatic merge failed in [lhcb-dd4hep#1151](https://lhcb-nightlies.web.cern.ch/nightly/lhcb-dd4hep/1151/LHCb/checkout
• [2022-06-07 00:07] Automatic merge failed in [lhcb-dd4hep#1152](https://lhcb-nightlies.web.cern.ch/nightly/lhcb-dd4hep/1152/LHCb/checkout
• [2022-06-09 00:05] Validation started with lhcb-dd4hep#1154
• [2022-06-10 00:04] Validation started with lhcb-dd4hep#1155
• [2022-06-10 11:48] Validation started with lhcb-dd4hep#1156
• [2022-06-10 15:09] Validation started with lhcb-dd4hep#1157
• [2022-06-11 00:04] Validation started with lhcb-dd4hep#1158
• [2022-06-12 00:04] Validation started with lhcb-dd4hep#1159
• [2022-06-13 16:08] Validation started with lhcb-dd4hep#1160
• [2022-06-14 00:05] Validation started with lhcb-dd4hep#1161
• [2022-06-14 12:20] Validation started with lhcb-dd4hep#1162
• [2022-06-15 00:05] Validation started with lhcb-dd4hep#1163
• [2022-06-16 00:05] Validation started with lhcb-dd4hep#1164
• [2022-06-16 14:46] Validation started with lhcb-dd4hep#1165
• [2022-06-17 00:05] Validation started with lhcb-dd4hep#1166
• [2022-06-17 11:41] Validation started with lhcb-dd4hep#1167
• [2022-06-17 17:25] Validation started with lhcb-dd4hep#1168
• [2022-06-18 00:05] Validation started with lhcb-dd4hep#1169
• [2022-06-18 09:01] Validation started with lhcb-dd4hep#1170
• [2022-06-19 00:04] Validation started with lhcb-dd4hep#1171
• [2022-06-20 00:04] Validation started with lhcb-dd4hep#1172
• [2022-06-20 10:43] Validation started with lhcb-dd4hep#1173
• [2022-06-20 16:14] Validation started with lhcb-dd4hep#1175
• [2022-06-21 00:04] Validation started with lhcb-dd4hep#1176
• [2022-06-22 00:05] Validation started with lhcb-dd4hep#1177
• [2022-06-23 00:04] Validation started with lhcb-dd4hep#1178
• [2022-06-24 00:04] Validation started with lhcb-dd4hep#1179
• [2022-06-24 00:04] Validation started with lhcb-dd4hep-g4units#1
• [2022-06-24 14:58] Validation started with lhcb-dd4hep-g4units#2
• [2022-06-25 00:04] Validation started with lhcb-dd4hep-g4units#3
• [2022-06-25 00:04] Validation started with lhcb-dd4hep#1181
• [2022-06-26 00:04] Validation started with lhcb-dd4hep#1182
• [2022-06-26 00:04] Validation started with lhcb-dd4hep-g4units#4
• [2022-06-27 00:04] Validation started with lhcb-dd4hep#1183
• [2022-06-27 00:04] Validation started with lhcb-dd4hep-g4units#5
• [2022-06-28 00:04] Validation started with lhcb-dd4hep-g4units#6
• [2022-06-28 00:05] Validation started with lhcb-dd4hep#1184
• [2022-06-28 09:46] Validation started with lhcb-dd4hep#1185
• [2022-06-29 00:05] Validation started with lhcb-dd4hep-g4units#7
• [2022-06-29 00:05] Validation started with lhcb-dd4hep#1186
• [2022-06-29 09:54] Validation started with lhcb-dd4hep#1187
• [2022-06-30 00:05] Validation started with lhcb-dd4hep#1188
• [2022-06-30 00:05] Validation started with lhcb-dd4hep-g4units#8
• [2022-07-01 00:04] Validation started with lhcb-dd4hep#1189
• [2022-07-01 00:05] Validation started with lhcb-dd4hep-g4units#9
• [2022-07-02 00:04] Validation started with lhcb-dd4hep#1190
• [2022-07-02 00:04] Validation started with lhcb-dd4hep-g4units#10
• [2022-07-04 16:31] Validation started with lhcb-dd4hep#1191
• [2022-07-05 00:05] Validation started with lhcb-dd4hep#1192
• [2022-07-05 00:05] Validation started with lhcb-dd4hep-g4units#11
• [2022-07-06 00:04] Validation started with lhcb-dd4hep#1193
• [2022-07-06 00:04] Validation started with lhcb-dd4hep-g4units#12
• [2022-07-07 00:04] Validation started with lhcb-dd4hep-g4units#13
• [2022-07-07 00:04] Validation started with lhcb-dd4hep#1194
• [2022-07-08 00:05] Validation started with lhcb-dd4hep#1195
• [2022-07-08 00:05] Validation started with lhcb-dd4hep-g4units#14
• [2022-07-09 00:04] Validation started with lhcb-dd4hep-g4units#15
• [2022-07-09 00:05] Validation started with lhcb-dd4hep#1196
• [2022-07-11 00:04] Validation started with lhcb-dd4hep#1197
• [2022-07-11 00:04] Validation started with lhcb-dd4hep-g4units#16
• [2022-07-12 00:05] Validation started with lhcb-dd4hep-g4units#17
• [2022-07-12 00:05] Validation started with lhcb-dd4hep#1198
• [2022-07-13 00:05] Validation started with lhcb-dd4hep-g4units#18
• [2022-07-13 00:05] Validation started with lhcb-dd4hep#1199
• [2022-07-14 00:05] Validation started with lhcb-dd4hep-g4units#19
• [2022-07-14 00:05] Validation started with lhcb-dd4hep#1200

removed dd4hep label

added dd4hep label

removed lhcb-dd4hep label

@jonrob I've dropped the lhcb-dd4hep flag for the moment, so that the tests ongoing there are not affected

I'm not convinced that forcing all derived conditions to be wrapped in an std::any is a good idea. It's a valid workaround for the cases were a default constructor (or a move assignment) is not possible, or for when the silly condition memory allocation enforced by DD4hep is causing trouble, but I believe that in those few cases we could just wrap the derived condition object in a std::unique_ptr, which is basically what happens when we use std::any.

added 28 commits

• 59483c61...b432ed71 - 27 commits from branch lhcb:master
• 4a598b9e - Pass std::any to dd4hep condition storage, to allow better type checking on LHCb side

Compare with previous version

added lhcb-dd4hep label

added 1 commit

• c8dd94fb - Add type traits to determine when to pass st::any to dd4hep conditions storage.

Compare with previous version

added 1 commit

• 35809965 - Add type traits to determine when to pass st::any to dd4hep conditions storage.

Compare with previous version

added 1 commit

• 8ca119a5 - Add type traits to determine when to pass st::any to dd4hep conditions storage.

Compare with previous version

added 15 commits

• 8ca119a5...a68f7239 - 13 commits from branch lhcb:master
• afa0f8d3 - Pass std::any to dd4hep condition storage, to allow better type checking on LHCb side
• f37dfa89 - Add type traits to determine when to pass st::any to dd4hep conditions storage.

Compare with previous version

marked this merge request as ready

changed the description