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.
Most of this is just tidying up the logic to (hopefully) be better to
follow, again (again (again)).
The actual fix is that we now allow interpolation/playback when the
incoming time is less than the first frame's time, regardless of
receiving status.
I want to prioritise better playback performance over accuracy for now. Also, in my testing this is still 100% accurate due to the addition of the FrameStabilityContainer, which is pretty cool.
