Add PTB HLT and LLT information to CAF files for real SBND data

[hbjamin]

Description

This PR adds PTB information to CAF files for real SBND data, which is required for trigger efficiency studies using zero bias data. The implementation extracts all HLT (High Level Trigger) and LLT (Low Level Trigger) information from PTB fragments, decodes trigger words into individual bits, and stores them separately in the CAF structure. This PR requires merging SBNSoftware/sbnanaobj#180

• Have you added a label? (bug/enhancement/physics etc.)
• Have you assigned at least 1 reviewer?
• Is this PR related to an open issue / project?
• Does this PR affect CAF data format? If so, please assign a CAF maintainer as additional reviewer.
• Does this PR require merging another PR in a different repository (such as sbnanobj/sbnobj etc.)? If so, please link it in the description.
• Are you submitting this PR on behalf of someone else who made the code changes? If so, please mention them in the description.

[fjnicolas]

Looks great @hbjamin! See comment in SBNSoftware/sbnanaobj#180 about uint64_t for the decoded HLT/LLT IDs

[terezakroupa]

Thanks Ben, looks great!

[PetrilloAtWork]

I have dropped a few technical suggestions.
But more importantly I would like the author to deeply think about the real need for a catch(...) in the code.

[hbjamin]

Thank you for the good suggestions. There was no reason for me to use a catch statement. It was leftover from my initial debugging of extractAllPTBInfo. I've also included several changes that result from making the timestamps a uint64_t that stores nanoseconds since UTC epoch instead of a double that stores seconds since UTC epoch to avoid rounding jumps occurring at 256 and 512 ns

[kjplows]

Thanks @hbjamin ! @PetrilloAtWork , do the changes look good to you? Thanks!

[kjplows]

Bumping this, if @PetrilloAtWork is happy we should merge this. Thanks!

[PetrilloAtWork]

I am going to approve the PR as I suppose that's "urgently" needed.
However, I invite the author to rethink the pattern and to update it: here we have a direct extraction from raw detector-specific data to the highest analysis level. That is a very strong coupling.
My recommendation is to move the extraction code into sbndcode producer module which puts the extracted information into a data product (std::vector<PTBInfo_t>), allowing CAF maker and anything else to access it without the need for artDAQ and the knowledge of low-level details on the data format.

[fjnicolas]

Hi @maxdubnowski @nathanielerowe! This PR involves some changes to the POTTools and the POT exposure accounting modules. Could you please have a look/approve if these look good to you? Thanks!

[nathanielerowe]

I don't understand some of the changes being made here. Why are we moving around factors in the data products? Was there a unit change somewhere?

[hbjamin]

I don't understand some of the changes being made here. Why are we moving around factors in the data products? Was there a unit change somewhere?

Hi @nathanielerowe the currPTBTimeStamp variable in the PTBInfo_t struct was changed to a uint64_t that stores nanoseconds since UTC epoch instead of a double that stores seconds since UTC epoch to avoid rounding jumps occurring at 256 and 512 ns

[nathanielerowe]

@hbjamin Gotcha, checking that it doesn't change the POT results now. Are these changes also made to the decoder module? A lot of the PTB product parsing code was copied from there.

[nathanielerowe]

Distributions match, looks good on my end!

[nathanielerowe]

Could maybe move extractAllPTBInfo elsewhere since it doesn't actually get used in the POT process, but fine if it stays!