Is your feature request related to a problem? Please describe.
This is more or less a rehash of #15886 which was closed due to staleness.

Consider the following:

• State ordering is done via requisites rather than order in a state tree, as recommended by the docs. For example, the following state IDs should follow this order: foo → bar → baz → quux, and thus bar has a require of foo, baz has a require of bar, and so forth.
  • (With the exception of one or two states which absolutely must be run very last, unquestionably, and thus have - order: last.)
• A master is configured with failhard: true with the intent of selectively setting failhard: false on explicit states that MAY fail, but failure state is acceptable. For example, foo is prone to failure, but its failure (or partial failure which would squash down to a failure since the result in ret is a boolean for most (all?) state/execution modules) is acceptable.
  • Thus in this scenario, foo has - failhard: False.
• bar is in an included SLS, and MUST ALWAYS proceed after foo regardless if it has failed or not. It is expected to/never should fail, and thus ITS failhard is implicitly True (as per the master configuration).
  • HOWEVER, because the only available ordering requisite appropriate for this is require, if foo fails then bar will never run. Even though it's supposed to. This means either its state fails, ending the entire run erroneously, or it necessitates a wholly and completely inappropriate - failhard: False as well, because...
• baz has a require for bar. This then means that baz will fail if bar fails, if bar still has the implicit failhard: True set, and will STILL never run (even though it should) IF foo FAILS, as thus its failure has now cascaded into baz and, as a result, baz faces the exact same conundrum re: failhard as bar above.
• This now leads to effectively setting failhard to False for the entire chain at bar onwards JUST to get quux to always run, which is incorrect for the expectations of bar, baz, and quux.

And so on, and so on. Leading to a cascading mess.

Describe the solution you'd like
Two new global requisites should be added:

• after (or reasonable analogue), a "softer" require that is strictly used for ordering dependency and not state dependency
• before (or reasonable analogue), a "softer" require_in (again tied strictly to ordering rather than state dependency)

with the intent that only after OR require in a given state for a given preceding state ID is given (and likewise for before/require_in).

Describe alternatives you've considered
The only possible alternative is duplicating every single state in the chain after the first "soft-fail" state, one with require and failhard: False and another with onfail and the implicit failhard: True. onfail does not execute if its preceding dependency SUCCEEDS, so it cannot be used alone without a paired require state. Using both require and onfail in the same state declaration for the same preceding state ID leads to a logic condition in which the state will never ever be run (they are AND'd instead of OR'd), but even if they were OR'd the state would STILL need the inappropriate - failhard: False.

This, as you can imagine, is tedious in larger state trees that may include conditional states:

$ find ./ -type f -name '*.sls' | wc -l
307

$ find ./ -type f -name '*.sls' -exec grep -Ec '^[A-Za-z0-9]+.*:\s*' '{}' \; | awk '{s+=$1} END {print s}'
1420

Additional context
N/A.

Please Note
If this feature request would be considered a substantial change or addition, this should go through a SEP process here https://github.com/saltstack/salt-enhancement-proposals, instead of a feature request.