Docs and examples on how to report performance issues

[MischaPanch]

RL is flaky and one needs to report statistically significant results. We should help contributors and users with this. I think using nni for parallel execution is a good fit for that (nni is dead, and we shouldn't rely on external tools unless strictly necessary, especially those needing external config files).

Original motivation:

I run 10 runs for each config and there wasn't much difference. I guess that was an unlucky v.s. lucky seed case

Originally posted by @MischaPanch in #886 (comment)

[MischaPanch]

Related to #978

[MischaPanch]

@bordeauxred this is essentially the task that you're currently working on, as a first step towards #978. Pls comment here so I can assign you :)

[bordeauxred]

Comment as requested @MischaPanch

[MischaPanch]

@maxhuettenrauch pls also comment so I can assign you

[maxhuettenrauch]

.

[MischaPanch]

After several discussions, the todos here became clearer:

• Allow setting policy random seeds and training seeds separately
• Allow setting training seeds explicitly
• Prevent accidental overlap between training seeds and test seeds

As the final outcome of this issue, there should be one script that allows training some policy with a fixed configuration on some environment such that after training one can clearly say one of the three:

1. With at least X_1 many training seeds and X_2 policy seeds, the performance of the policy is good on non-training seeds. The interquantile mean is high and the interquantile variance is small.
2. With at least X_1 many training seeds and X_2 policy seeds, the performance of the policy is bad (small mean, still small variance)
3. The variance is so large that the results are inconclusive. It may mean that either the number of training seeds should be changed (we got unlucky a few times but with more training seeds the sample efficiency may improve), or that overall the algorithm-env combination has intrinsically high variance and is prone to something like collapse to bad solutions.

In any case, after running such a script there should be as few questions left regarding randomness and flakyness as possible. The runs should be exactly reproducible. The relevant statistics should be easily visualizable (in particular, interquantile statistics), maybe some plots should be saved as png by default. Additional statistics can be collected with ease.

We can think about an integration with rliable and openrlbenchmark, but it's not a priority and can be done later. Maybe some code from rliable can help us here.

Note that the algorithm configuration should ideally be written in python. We can use systems like hydra or optuna to parallelize runs, but we should not rely on their yaml-based configuration mechanisms.

The configspace project might be a good fit for describing our configuration. Note also my PR there that introduces better typing support for sampling configurations. Until it's merged, we could put the configspace extension into tianshou for the time being.

@maxhuettenrauch @opcode81