Jobs/Burst based substepping

Replace the managed thread based substepping sim with a Jobs/Burst implementation.

Overview of the substep sim :

In SubStepSim.OnFixedUpdate() (called by Kerbalism.FixedUpdate() before anything else has been done) :

Wait for your background worker to have finished (if he hasn't already)
For every simulated vessel, from the collection used by the background workers to store "future steps" for this vessel, remove all steps whose UT < the current UT, and store them in a collection accessible from the VesselData class with managed code, and that can safely be read/write from the main thread.
Update your "job-safe" versions of all vessels/bodies and their orbits with the current KSP position/frame/parameters
Compute maxFutureUT, the maximum time in the future that might be attained in the next fixedupdate at max timewarp : currentUT + (TimeWarp.fetch.warpRates[7] * 0.02) + one extra substep just in case
Start your background worker, computing all steps for all vessels, starting from the last already stored step UT up to maxFutureUT

Later in Kerbalism.FixedUpdate(), VesselData.EnvironmentUpdate will be called. The elapsedSeconds parameter is checked against the substep duration "constant" (60s for example).

If elapsedSecond < substepDuration * 2.0 :

Remove all steps whose UT < current UT from the "main thread-safe" step collection that you updated in SubStepSim.OnFixedUpdate()
Create a new step
Directly copy the vessel position and bodies position from the current ones as defined by KSP to the "job-compatible" data structures (or, in case that's possible, you can use the ones you already updated in SubStepSim.OnFixedUpdate())
Run the step evaluation (occlusion, fluxes, etc)
Wait for the results and copy them back in the corresponding VesselData managed data structures

else

Get the "main thread-safe" collection of steps for that vessel that you updated in SubStepSim.OnFixedUpdate()
Iterate on those to compute scalar factors or average values for the results (occlusion, fluxes, etc)
Copy those results in the corresponding VesselData managed data structures
Clear the "main thread-safe" step collection

Data : current implementation performance

Single threaded blocking implementation (main thread will wait for the worker to finish)
30s substeps
20 vessels in orbit around various stock bodies
Space center scene, max stock warp (100.000x)

Save : 20 vessels.zip

Profiler results (2C/4T@4.5Ghz, Cinebench R20 MT : 1135 / ST : 453) :

Relevant metrics :

Sim thread : substepping thread processing time
Sim lag : time spent blocking the main thread waiting for the sim thread to finish
Sim sync : time spent synchronizing data between KSP/Kerbalism objects and the thread safe objects
Sim processing : time spent processing the substeps in the main thread

Inclusion of radiation evaluation

Like irradiances, radiation evaluation is also subject to huge inaccuracies at high timewarp rates. Ideally, we should move it to the substep simulation. Said plainly, that whole portion of code : https://github.com/Kerbalism/Kerbalism4/blob/1e390eb8ef80632d9a641641f07a571ad1492a49/src/Kerbalism/Database/VesselData/VesselData.cs#L979-L1002 In terms of final output, this translate into getting substepped averages (instead of "current position") for the following VesselData radiation rates (rad/s):

/// <summary> ambiant radiation from the inner belt</summary>
public virtual double EnvRadiationInnerBelt { get; }

/// <summary> ambiant radiation from the outer belt</summary>
public virtual double EnvRadiationOuterBelt { get; }

/// <summary> ambiant radiation from the magnetopause</summary>
public virtual double EnvRadiationMagnetopause { get; }

/// <summary> directional radiation from the surface</summary>
public virtual double EnvRadiationBodies { get; }

/// <summary> directional radiation from the sun(s)</summary>
public virtual double EnvRadiationSolar { get; }

 /// <summary> directional radiation from solar storm</summary>
public virtual double EnvStormRadiation { get; }

/// <summary> proportion of ionizing radiation not blocked by atmosphere</summary>
public virtual double EnvGammaTransparency  { get; }

The current code is a bit messy. The core method to port is the Radiation.Compute() method (which is currently a bit messy and was pending a refactor/cleanup) : https://github.com/Kerbalism/Kerbalism4/blob/1e390eb8ef80632d9a641641f07a571ad1492a49/src/Kerbalism/Radiation/Radiation.cs#L618-L770

You will notice that for each of the above variable, there is a matching boolean. This is because we used to only output the "total" aggregate radiation, and booleans to identify what sources were "active". I quick-and-dirty changed that recently so we have access to the detail rate of each source, but I was also in the process of refactoring the whole thing so EnvRadiationSolar is tracked per sun, and EnvRadiationBodies per body (because they are directional, and I was planning to take that into account, at least for solar radiation). Said otherwise, I intended to move EnvRadiationSolar to the StarFlux structure. But since you already are in the process of extending/refactoring StarFlux to a BodyFlux structure (and processing all bodies internally), we should likely do both from the ground up.

In terms of re-implementation, a quick overview :

You will need to make a "job-safe" copy of the RadiationBody and RadiationModel data structures. All values in those classes are constants, so you only need to make that once. RadiationModel are essentially "templates", so I suggest you aggregate the data in a single "per body" data structure (and in fact, you should use the same data structure for info about stars too, instead of re-getting it every iteration. This is also constant data.)

Belts and magnetopause radiation are computed by evaluating the vessel position against the fields shape, which are represented by math functions. The called methods are a bit all over the place for no reason other than technical debt, but you should be able to rebuild the execution path quite easily by following the execution of Radiation.Compute() (it's entirely self contained, to my knowledge there is nothing modifying the data that this depends on).

Solar/bodies radiation are directional, and affected by other bodies occlusion (and also, they are the same value in RadiationModel). From a physics POV, they are identical to the solar irradiance, so you can likely just merge that into your existing code.

Storm radiation is a bit trickier. As mentioned in #5, I intended to more or less entirely scrap the current per-vessel-random implementation, possibly in favor of generating "cone" storms, where every vessel/body inside the cone is subject to the storm. For now, I would suggest to postpone including storm radiation in the substep sim until this is done.

Kerbalism / Kerbalism4