allow using any stage as a startup stage

[mockersf]

Fixes #2246, #2229

• methods add_stage, add_stage_before and add_stage_after also adds an empty stage with the same label to the startup schedule
• all CoreStage are added to the startup schedule
• StartupStages now work as aliases of matching CoreStages (Startup -> Update, PreStartup -> PreUpdate, PostStartup -> PostUpdate)

This means:

• for the default use case, no more surprising differences between startup and normal stages
• extra stages are added to the startup schedule, but it shouldn't impact much as they'll remain empty and only run once
• for the advanced user, nothing changed and they can still add custom stages with the explicit StartupStage

[alice-i-cecile]

This is a bit magical; I'm not sure how I feel about doing all of this implicitly. It will solve the new user confusion there, but I'm a bit nervous about obscuring the correct mental model.

[cart]

Yup I think it makes the system much harder to reason about. I think we should consider alternatives, such as:

1. Just hard-code a better error message for this specific case (not a huge fan of this, but at least it is scoped)
2. Remove the "subschedule" in favor of separate PreStartup/Startup/PostStartup stages in the main schedule (each with their own runonce run criteria).
3. Other
4. Ideas
5. Here 😄

[mockersf]

This is a bit magical

But it was fun magic to write!

It completely abuses the dynamic traits we have though.

[Ratysz]

Implementation does look like abuse on a level even greater than the dyn hack itself 😄

Both of the linked problems are, in essence, user errors. I don't think we need any new kind of automagic here: what we have now makes perfect sense once you realise what's going on (i.e. that the startup stage contains the startup schedule with its own stages). So, we just need better docs and a specialized, more descriptive error.

[Ratysz]

Another idea: pub trait StartupStageLabel.

[cart]

Another idea: pub trait StartupStageLabel.

This solves this specific problem, but it would require hard-coding "startup stage labels" into Schedule right? Not sure I want to compromise a "generic" api for a specific use case.

[Ratysz]

hard-coding

Oh. I missed that. Yeah, that idea just went from "ehh" to "no way" in my head.

[alice-i-cecile]

2. Remove the "subschedule" in favor of separate PreStartup/Startup/PostStartup stages in the main schedule (each with their own runonce run criteria).

I like this a lot as a solution; I think it's much clearer for beginners and doesn't involve any trickery. I don't see any good occasions where end users will want to refer to all startup stages at once in a way that the nested stages encourage.

[alice-i-cecile]

I think the consensus on this is pretty 👎🏽 @mockersf <3 Going to close this out and we can look at this problem in #2801's schedule overhaul.