IdealStateCreator creating not so ideal states

I've found this issue while trying to fix the RICH1 states created in the PrKalmanFilter (reported in Panoptes!116 (merged), fixed in !2414 (merged))

The prior method of creating the RICH1 states in the PrKalmanFilter seemed to work, aside from producing suboptimal pulls.
We normally test this via the TrackResChecker which for any given state we want to check, asks the IdealStateCreator for the "true" state. Let's only focus on the BegRich1 state as the problem is most obvious for that one.
Take for example this comparison of the x-{resolution, pull} between the TrackMasterFitter and PrKalmanFilter

We see that technically we seem to produce a state that has a better resolution and our prediction is more often in the range shown in the histogram.

However, the problem that I found is in the way the IdealStateCreator creates our truth that we compare to.
It does so by picking the closest MCHit to our reconstructed state and then extrapolating that information to the z-position of said reconstructed state.
For BegRich1 this means the last MCHit in the VELO, which is then extrapolated all the way to z=990mm (z of BegRich1).
This by definition is unfortunately not ideal.
The plot above shows better performance for the PrKalmanFilter because that algorithm uses the same approach of simply extrapolating from the last velo hit, thus it's not actually better than the TrackMasterFitter, it is just wrong in the same way the IdealStateCreator is... 🤦

There are essentially 2 ways I see to make the IdealStateCreator better:

1. Create states like the BegRich1 that are "far" away from a MCHit by interpolating between two MCHits instead of extrapolating from only 1.
2. Personal Preference: Make sure we have actual MC information at these specific state locations, instead of trying to somehow reconstruct that truth.

Thanks to @jonrob for the help and pointing me towards the RichMCSegments!

I've in my own stack hacked together a version which piggy backs off of the MCRichSegements.
These segments contain information on the path that the MCParticle took through the radiator medium.
Thus, I've modified the IdealStateCreator to take these into account, as they provide MC info very close to our BegRich1 state.
Now our comparison plot from above looks like this:

So the world makes sense again, PrKalmanFilter is actually worse, and we can fix that -> !2414 (merged)

IMHO, we should fix the IdealStateCreator to make use of additional MC-Info!
But while the locations in our XDIGI files are there, they aren't actually filled with any useful information but only zeroes... 🙄
With help from the simulation mailing list @ldufour and I were able to figure out that there is a special Gauss option UpgradeRICHSimRunOption that enables the writing of these RichMCSegments.
So the test above is actually based on some black market handcrafted super-duper simulation that @ldufour made for me :)

I'm in touch with the simulation group to see what's possible here. We don't actually need the apparently very costly to produce RichMCSegments. They were just used above because right now it's all we got.
It would be enough to essentially have a "fake" MCHit at certain special z-positions.

cc: @cmarinbe @decianm @ldufour @wouter