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 is a workaround of a timing issue.
KeyCounter is disabled while break time (`HasCompleted == true`).
When the last keypress is exactly at the same time the map ends, the last frame was considered in a break time while forward play but considered not in a break time while rewinding. This inconsistency made the last keypress not decremented in the key counter when a replay is rewound.
The situation regularly happens in osu!standard because the map ends right after the player hits the last hit circle. It was caught by `TestSceneGameplayRewinding`.
This commit makes the update of the map completion delayed one frame. The problematic keypress frame is now processed strictly before the map completion, and the map completion status is correctly rewound before the keypress frame.
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.
While it is the case for the existing official Skills, Skill implementations shouldn't be required to conform to a strain based approach.
There are other valid approaches to calculating skill difficulty that can be supported by abstracting the strain logic into its own StrainSkill class.
As strains are an implementation detail of the current Skill calculations, it makes sense that strain related logic should be encapsulated within the Skill class.
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.
