Timeprovider advance multiple invocations

[egil]

This fixes #3995. These are the changes I have included:

1. The FakeTimeProviderTimer.Waiter now tracks when a WakeupTime was scheduled. It does this to ensure that the callbacks are invoked in the order they are scheduled in.
2. FakeTimeProviderTimer now triggers callbacks one at a time, and allows their callbacks to add reschedule themselves or influence other timers/create new timers.
3. FakeTimeProvider exposes an Epoch property, which represents the initial start time when the time provider was instantiated. It is a useful value to have available during testing, e.g. if you have to call SetUtcNow multiple times during a test, and the value you are setting is changed in relation to the start time/epoch. It tends to lead to easier-to-understand test code in my experience.
   I also changed the ctor argument startTime on FakeTimeProvider to epoch to match the name of the added property.
4. Changed Advance() and SetUtcNow() to prevent moving time back.

Microsoft Reviewers: Open in CodeFlow

[egil]

I didn't want to change too much of the existing implementation, but an alternative approach to implementing this I've used in my ManualTimeProvider is to only hold waiters in the FakeTimeProvider.Waiters collection in while their timer has a scheduled callback, and keep the waiters sorted by WakeupTime. That would eliminate the need for the Waiter.ScheduledOn property but would be a bigger change to the existing implementation.

[RussKie]

Few nits

[RussKie]

I had a brief chat with @sebastienros, and it looks like I may have misinterpreted his comments. I am removing myself from this PR and letting @sebastienros and @geeknoid take over the reviews.

[sebastienros]

Could it use the standard Try... pattern by being bool TryGetWaiterToWake(DateTimeOffset targetNow, out FakeTimeProviderTimer.Waiter?)

[egil]

Yes. But please indulge me, why?

I would use the common bool TryGetX(Foo foo, out Foo bar) in a public API surface since that is a very recognizable pattern in the .NET ecosystem. For private/internal stuff, I have changed to this pattern since we now have nullable reference types and pattern matching, I feel this version is more direct, clean, and doesn't involve out arguments. I am fairly certain that had these language features been around in the early days, the TryGetX pattern would not be the norm.

I do respect that you may have a coding standard in this repo you like to follow (I admit I didn't look at other projects in the repo, just this one) and I would change it regardless if you prefer the other style.

[egil]

@sebastienros / @geeknoid I've added you to my fork of the repo so you can push changes to this PR as you see fit.

[egil]

Let me add the missing experimental attribute to the ctor and push a rewrite of the git history that bundles up the feedback into clean commits.

Ps. I do not have the permissions to merge the PR.