Making those always non-null is postponed as when a replay's frame contains keypress the behavior is changed.
Previously, the key is pressed at the time of the first frame. But using non-null frames means the key is pressed at negative infinity.
However, I think the new way of always using non-null frames makes the client code so I plan to bundle the change to more breaking changes.
This commit changes the semantics of `CurrentFrame` and `NextFrame` of the class.
The ordering of `NextFrame.Time` and `CurrentFrame.Time` was dependent on the current direction.
Now, it should always satisfy `CurrentFrame.Time <= CurrentTime <= NextFrame.Time` except at the start/end.
This change, however, doesn't break existing deriving classes if the template code pattern usage of interpolation is used.
The deriving class code can be simplified due to the elimination of nullable types. I didn't include those changes in this commit.
I removed `StreamingFramedReplayInputHandlerTest` for now, as it is almost-duplicate of `FramedReplayInputHandlerTest`. I'll include more tests in later commits.
This commit fixes#6150.
There is no reason we should be limiting skills to knowing only the previous 2 objects. This originally existed as an angle implementation detail of the original pp+ codebase which made its way here, but didn't get used in the same way.
Although this isn't necessary for existing official rulesets and calculators, custom calculators can have use cases for accessing mods in difficulty calculation.
For example, accounting for the effects of visual mods.
Importantly, this removes the call to CatchUnobservedExceptions(), which was
outright incorrect (awaiting on the wrong task as a result) in the
original test code.
It needs to be explicitly stated that the users in this list are related
to the *joined* room. Especially since it's sharing its variable name
with `SpectatorStreamingClient` where it has the opposite meaning (is a
list of *globally* playing players).
