New tracker conditions tables for TOT and HV trips

[bonventre]

Adds three new database tables. Two tables implementing the TOT=>drift time calibration, and one table to hold a list of HV trips. Since trips are expected to be within a run/subrun, they are stored as a list of panels + start and end event id

[FNALbuild]

Hi @bonventre,
You have proposed changes to files in these packages:

• DbTables
• TrkHitReco
• CosmicReco
• Filters
• TrackerConditions
• TrackerMC

which require these tests: build.

@Mu2e/fnalbuild-users, @Mu2e/write have access to CI actions on main.

⌛ The following tests have been triggered for 98cf831: build (Build queue - API unavailable)

About FNALbuild. Code review on Mu2e/Offline.

[FNALbuild]

☔ The build tests failed for 98cf831.

Test	Result	Details
test with	✅	Command did not list any other PRs to include
merge	✅	Merged 98cf831 at 95f0a83
build (prof)	✅	Log file. Build time: 04 min 09 sec
ceSimReco	❌	Log file. Return Code 1.
g4test_03MT	✅	Log file.
transportOnly	✅	Log file.
POT	✅	Log file.
g4study	✅	Log file.
cosmicSimReco	✅	Log file.
cosmicOffSpill	❌	Log file. Return Code 1.
ceSteps	✅	Log file.
ceDigi	❌	Log file. Return Code 1.
muDauSteps	✅	Log file.
ceMix	❌	Log file. Return Code 1.
rootOverlaps	✅	Log file.
g4surfaceCheck	✅	Log file.
trigger	❌	Log file. Return Code 2.
check_cmake	✅	Log file.
FIXME, TODO	➡️	TODO (7) FIXME (10) in 20 files
clang-tidy	➡️	14 errors 367 warnings
whitespace check	✅	no whitespace errors found

N.B. These results were obtained from a build of this Pull Request at 98cf831 after being merged into the base branch at 95f0a83.

For more information, please check the job page here.
Build artifacts are deleted after 5 days. If this is not desired, select Keep this build forever on the job page.

[rlcee]

I know we talked about this before, but I don't recall the conclusion. What will knowing trips do for reco?
If a trip can cross a subrun boundary, it might need the subrun number, since currently event number has to be reset at each subrun
If Panels trip, the row should return a PanelId
we have a guideline of one class definition per include file
I'd be concerned for the per-table overhead, and the two tables can get out of sync - you decided against the one-table designs?
The rest of the implementation looks straightforward

[bonventre]

Right now the impact in actual reco of the trip table is small (hits in those panels are assumed to be noise and excluded), but then also used to update hit status flags which we need correct in EventNtuple to do efficiency calculations etc. I'm not sure if there's a good way to do that efficiently in a post-reco analysis only step.

I've adjust the TOT table to one of the other options we discussed, which was a space separated text field for the array values instead. Performancewise you think this is the better approach here?

[rlcee]

Performance-wise I think going from 3 tables to 2, is a notable improvement. After that, it is hard to say. Thanks