Add new trigger CAF variables to trigger StandardRecord

[npallat]

Description

This includes new trigger CAF variables to trigger StandardRecord, specifically a bool of passed/failed trigger, number of PMT pairs over threshold, and two variables for the purpose of validation giving us the trigger response in a flattened vector and the size of the pulses (so the vector can be un-flattened).

Checklist

• Added at least 1 label from available labels.
• Assigned at least 1 reviewer under Reviewers,
• Assigned all contributers including yourself under Assignees
• Linked any relevant issues under Developement
• Does this PR affect CAF data format? If so, please assign a CAF maintainer ([PetrilloAtWork])
• Does this affect the standard workflow? [No]
• Is this PR a patch for the ongoing production? If so, separate PR must also be made for production/v10_06_00 branch! [These changes are for the validation production, not the ongoing production/v10_06_00 ]

Relevant PR links (optional)

Yes, this needs to be merged after the changes to detsim (where these data products are created and added to the event) and with updates to sbncode and sbnobj.

Link(s) to docdb describing changes (optional)

Is there a docdb describing the issue this solves or the feature added?
Here are a couple relevant links to presentations on this work:

• Update at Trigger Workshop: DocDB-43231
• Update at Simulation meeting: DocDB-42969

[PetrilloAtWork]

It's not clear from the description what the two levels in the vector<vector<int>> represent.
It would be good to explain that in the documentation.

[PetrilloAtWork]

The new variables need to be initialized in the constructor, which seems not to be happening (the .cxx file is not included in the PR). The std::vector objects are constructed empty by default, so they don't need explicit initialisation if "empty" is a good default. The passed_trigger should likely be initialised to false, and num_pairs_over_threshold to caf::kUninitializedInt (need to #include "sbnanaobj/StandardRecord/SRConstants.h").

Incidentally, this kind of oversights is the reason why I recommend initialisation in the definition of the class rather than in the constructor — but that hasn't been the custom in CAF. 🤷

[kjplows]

Technically dismissing the review from @PetrilloAtWork after offline follow up that confirms changes satisfy the review (can't log in to GIthub at the moment to hit "Approve")

Offline followup from @PetrilloAtWork confirms changes are good but can't login to Github to approve changes. Dismissing review to clear the "requested changes" flag

[kjplows]

trigger build LArSoft/lar*@LARSOFT_SUITE_v10_10_03

[FNALbuild]

✔️ CI build for LArSoft Succeeded on slf7 for c14:prof -- details available through the CI dashboard

[FNALbuild]

✔️ CI build for LArSoft Succeeded on slf7 for e26:prof -- details available through the CI dashboard

[FNALbuild]

❌ CI build for SBND Failed at phase build SBND on slf7 for c14:prof -- details available through the CI dashboard

🚨 For more details about the failed phase, check the build SBND phase logs

parent CI build details are available through the CI dashboard

[FNALbuild]

❌ CI build for ICARUS Failed at phase build ICARUS on slf7 for c14:prof -- details available through the CI dashboard

🚨 For more details about the failed phase, check the build ICARUS phase logs

parent CI build details are available through the CI dashboard

[FNALbuild]

⚠️ CI build for SBND Warning at phase ci_tests SBND on slf7 for e26:prof - ignored warnings for build -- details available through the CI dashboard

🚨 For more details about the warning phase, check the ci_tests SBND phase logs

parent CI build details are available through the CI dashboard

[FNALbuild]

❌ CI build for ICARUS Failed at phase ci_tests ICARUS on slf7 for e26:prof - ignored warnings for build -- details available through the CI dashboard

🚨 For more details about the failed phase, check the ci_tests ICARUS phase logs

parent CI build details are available through the CI dashboard