Optimize param validation through get_param(...) -> Option<Out>

[MiniaczQ]

Objective

Fixes #15505 through a new solution which came up during development.
It changes some of the original assumptions about checking all system params before running the systems,
which isn't correct for combinator systems (they can invalidate their own sub-system params).
Alternative to #15571

Solution

get_param returns an Option, which makes run_unsafe also return an option.
validate_param now defaults to get_param().is_some() and we overwrite it for non-send and grouped params to behave correctly.

The original assumption about validating all params before running a system is no longer valid.
Combinator system can invalidate it's own params in a case of:
a.pipe(b).pipe(a) where b removes required params for a.
Because of that, we will no longer validate all params of a system, but only those of the first one.
This allows us to prevent spawning tasks if we cannot start running a system and reduced access overhead, because we only check a single subsystem's params immediately followed by getting them (albeit in another thread).

Testing

Ran parts of CI locally,
Ran fallible_params example.

[MiniaczQ]

The steps taken to get here look as following:

1. We question whether 1.2 (from Optimize validate_param #15505) is possible to implement. While lifetimes and type erasure can be worked around, we can't fetch all system parameters ahead of running the system, because in case of compound systems (e.g. a.pipe(b)), the respective sub-systems can have mutually exclusive access. While this isn't technically UB, since the parameters will only be used in mutually exclusive contexts, this will lead to multiple im-/mutable references to the same data existing at once.
2. To get to 1.2, we need proposition 1.1 anyways. It gives better internal ergonomics than current solution. Because it's only applied when running systems, we don't save on tasks in multithreaded executors nor do we retain the original behavior of running only entire compound systems in executors (e.g. a.pipe(b) could run a but stop at b since params were "checked" lazily).
3. We can fix that by reintroducing validate_param, but default it's implementation as get_param().is_some(). We expect this implementation to be optimized by compiler. Because default implementation breaks for non-send resources, we overwrite it. We also overwrite it for compound resources (SystemParam tuples, ParamSet, DynSystemParam) to rely on their sub-params implementations.

To sum it up, without going the additional step into proposition 1.2 we simply cannot reduce double checks in executors.

An alternative to 1.2 idea could split "fetching" into 2 steps:

• checking availability and creating an "access key" - validate_param() -> Option<Accessor>
• using the "access key" to construct system params - get_param(Accessor)
• to avoid additional boxing in executors, Acccessors can be stored inside the bottom-level Systems (exclusive/function) when fetch succeeds and removed after running the system.

[MiniaczQ]

Marking it as ready for review since code is basically done, just needs benchmarks

[MiniaczQ]

Note for @alice-i-cecile, since I've only made groundwork towards 1.2, but not implemented it, this doesn't have a significant impact on performance and we can delay it.
I've had trouble finding all the broken code, but now that I've done it once it should go much quicker

[MiniaczQ]

I found an edge case that asks for change in requirements:
https://discord.com/channels/691052431525675048/749335865876021248/1292140022375514145
I'm re-drafting this until I implement it

[MiniaczQ]

Core changes are done, just need to update documentation

[MiniaczQ]

Before (main):

param/combinator_system/8_piped_systems
                        time:   [1.6549 µs 1.6689 µs 1.6852 µs]
                        change: [-13.250% -10.268% -7.3630%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 2 outliers among 100 measurements (2.00%)
  1 (1.00%) high mild
  1 (1.00%) high severe

param/combinator_system/8_dyn_params_system
                        time:   [95.545 ns 95.841 ns 96.172 ns]
                        change: [-2.9593% -1.3542% -0.0548%] (p = 0.06 > 0.05)
                        No change in performance detected.
Found 5 outliers among 100 measurements (5.00%)
  3 (3.00%) high mild
  2 (2.00%) high severe

param/combinator_system/8_variant_param_set_system
                        time:   [91.596 ns 91.962 ns 92.365 ns]
                        change: [+0.1790% +1.0297% +1.8957%] (p = 0.02 < 0.05)
                        Change within noise threshold.
Found 9 outliers among 100 measurements (9.00%)
  6 (6.00%) high mild
  3 (3.00%) high severe

After:

param/combinator_system/8_piped_systems
                        time:   [1.6590 µs 1.6863 µs 1.7149 µs]
                        change: [-3.5415% -1.5778% +0.5378%] (p = 0.15 > 0.05)
                        No change in performance detected.
Found 4 outliers among 100 measurements (4.00%)
  4 (4.00%) high mild

param/combinator_system/8_dyn_params_system
                        time:   [93.629 ns 94.065 ns 94.551 ns]
                        change: [-2.3199% -1.2717% -0.1379%] (p = 0.01 < 0.05)
                        Change within noise threshold.
Found 4 outliers among 100 measurements (4.00%)
  2 (2.00%) high mild
  2 (2.00%) high severe

param/combinator_system/8_variant_param_set_system
                        time:   [91.913 ns 92.361 ns 92.842 ns]
                        change: [+0.0434% +0.8115% +1.6509%] (p = 0.05 < 0.05)
                        Change within noise threshold.
Found 4 outliers among 100 measurements (4.00%)
  3 (3.00%) high mild
  1 (1.00%) high severe

There is a lot of noise in the measurements, but at the very least I don't think this is a regression

It'd be good if few more people measured, I use cargo bench -- param/
Here is the specific main commit I used acbed6040eeae99199657e44a9668772738ac344.