Update track fit EDM

[osbornjd]

Briefly, what does this PR introduce?

This introduces changes to the track fit and track state EDM objects to better conform to a single container that can deliver all of the needs of downstream reconstruction algorithms and (ultimately) physics analysis.

1. Introduces a 6D covariance matrix object that is really the upper triangle of a full 6x6 covariance, for storage purposes.
2. Moves some "track level" quantities out from edm4eic::Trajectory and into edm4eic::Track
3. Revamps the edm4eic::TrackParameters object, which will need to contain the complete covariance to swap between edm4eic and Acts::EDM. Also adds a surface type as bound track parameters make no sense without an associated surface.
4. Adds a full covariance, position, and PID hypothesis to edm4eic::Track

The resulting track object contains the set of track parameters at the vertex, some criteria to evaluate the track fit (e.g. those contained in the one to one relation to edm4eic::Trajectory), and all track states associated to the fit (also still in edm4eic::Trajectory).

The track parameters at the vertex do need to be stored separately (e.g. not as another uniquely defined track state), for a technical reason. They are going to (1) be most frequently used in global coordinates, which the track parameters are not in and (2) are associated to a PerigeeSurface, which is transient unlike the surfaces associated with the actual geometry. Without knowledge of the surface, a set of BoundTrackParameters do not have a well defined global definition.

Opening this PR now as it will likely have nontrivial downstream consequences, so comments welcome.

What kind of change does this PR introduce?

• Bug fix (issue #__)
• New feature (issue #__)
• Documentation update
• Other: __

Please check if this PR fulfills the following:

• Tests for the changes have been added
• Documentation has been added / updated
• Changes have been communicated to collaborators

Does this PR introduce breaking changes? What changes might users need to make to their code?

It introduces breaking changes to EICrecon. Currently there are 3 containers produced by the CKF in EICrecon - the aim of this PR is to reduce this to a single container. This will in turn change other downstream reconstruction algorithms that rely on the CKF output as they will have to access this changed structure.

Does this PR change default behavior?

No

[wdconinc]

1. Propagate the Cov6f interface to make other Cov2,3f components identical in API, even if possible regression.
   • this can be addressed in a separate PR
2. Vector3f for track vertex position is not how we can constrain tracks, and I'd want that in the Vertex
   • Ideally Track is what comes out of CKFTracking, and we cannot add a vertex later through IVF. So what would this be filled with?
3. Cov6f for track position and momentum in cartesian components is unlikely to be calculable.
   • How do we get these cross correlations? Does Acts give those as output from IVF? Does it make sense to have these in cartesian vs spherical coordinates for momentum? Or will we provide a Jacobian to get from one to the other? I like the idea to allow full covariance, but I don't know if this is the coordinate system that makes most sense.

[osbornjd]

1. Propagate the Cov6f interface to make other Cov2,3f components identical in API, even if possible regression.

   * this can be addressed in a separate PR
   

That makes sense.

2. Vector3f for track vertex position is not how we can constrain tracks, and I'd want that in the Vertex
   
   * Ideally Track is what comes out of CKFTracking, and we cannot add a vertex later through IVF. So what would this be filled with?

This is not a vertex position, this is the track position of closest approach to the vertex (or some, in the case of Acts, PerigeeSurface which is right now by default set to (0,0,0) in the CKF). A set of track parameters can't be uniquely defined without a position.

3. Cov6f for track position and momentum in cartesian components is unlikely to be calculable.
   
   * How do we get these cross correlations? Does Acts give those as output from IVF? Does it make sense to have these in cartesian vs spherical coordinates for momentum? Or will we provide a Jacobian to get from one to the other? I like the idea to allow full covariance, but I don't know if this is the coordinate system that makes most sense.

It is calculable via jacobians that relate the two bases, there are transforms that do this that you can basically copy from the CovarianceEngine within Acts. I'll emphasize that this covariance has nothing to do with a vertex, it is on the track position itself WRT a PerigeeSurface. My personal opinion is that it does not make sense to store a covariance in local coordinates because it has no physical meaning without an associated surface, and the track parameters at a PerigeeSurface can change depending on where they are propagated (e.g. if they were determined at a primary vs. secondary vertex or something of this nature). Analyzers will, unless I am mistaken, work in global coordinates and the covariance is needed to determine things like the uncertainty on the DCA. We are either going to have to provide the parameters at the perigee surface in global coordinates, or provide them in local coordinates + a surface and additionally provide analyzers with a standard way to transform to global

[wdconinc]

Sounds good to me. Up to @sly2j to click the merge button.

[osbornjd]

So for my own understanding - this gets merged first and then we make the corresponding changes to EICrecon that will reflect these changes? I'm pretty sure merging this will break the nightly build

[wdconinc]

The nightly build in eic-shell doesn't pull in the main branch of just anything, only epic and eicrecon. So merging this doesn't mean it gets into eic-shell. We first need to cut a release here and put it explicitly in eic-shell.

[osbornjd]

Thanks for the clarification, I naively assumed all the repos got built together rather than some being only released on versions and some not. That makes sense for repos that don't change as frequently as others

[wdconinc]

There's the eternal tension between only putting releases into the environments rolled out to users by default, and putting only rolling main versions into the nightly. I wish we could have a nightly that's just main only but it's not workable and leads to too much breakage. So we've settled on epic and eicrecon main only... And there's pressure even here, in particular when changing acts versions in non-compatible ways wrt eicrecon.