Multiple context references are in flight for track fitters and finder

[andiwand]

After #3181 we have multiple context references in flight for track fitting and finding as they are bound in the algorithm options and propagation options.

acts/Core/include/Acts/TrackFitting/KalmanFitter.hpp

Lines 126 to 130 in 05c0ebd

	KalmanFitterOptions(const GeometryContext& gctx,
	const MagneticFieldContext& mctx,
	std::reference_wrapper<const CalibrationContext> cctx,
	KalmanFitterExtensions<traj_t> extensions_,
	const PropagatorPlainOptions& pOptions,

(context if part of KalmanFitterOptions and PropagatorPlainOptions)

This is not necessarily bad as it consumed little space but might be a source of errors as users could provide two different context objects for a single track fit.

A proposed solution is to decouple the options from the context and always provide context references explicitly as a parameters and never bind to them inside options. This also has the benefit of not making the options non-copyable (in case of a reference) or non-movable (in case of a reference wrapper) or to deal with potentially uninitialized pointers to context objects. A series of PRs are open to showcase these proposed changes:

• refactor!: Move context from PropagatorOptions to propagate #3378
• refactor!: Move context from fitter options to fitter calls #3379
• refactor!: Move context from material mapping options to material mapping calls #3381
• refactor!: Move context from vertexing options to vertexing calls #3380
• refactor!: Move context from stepper state to stepper calls #3382

One downside of this solution is that we potentially end up with a bunch of function parameters. This could be mitigated by binding multiple context objects into a tuple-like struct.

Apart from that it becomes very clear which parts of the code require a context and how this is passed down.

[paulgessinger]

We could introduce a non-null pointer wrapper that is both movable and copyable.

[github-actions]

This issue/PR has been automatically marked as stale because it has not had recent activity. The stale label will be removed if any interaction occurs.

[github-actions]

This issue/PR has been automatically marked as stale because it has not had recent activity. The stale label will be removed if any interaction occurs.