Using new TimeProvider

[Tratcher]

Fixes #2084

IClock was the only public abstraction type, it's been marked obsolete. It also wasn't consumed publicly anywhere, only internally via DI. All other internal abstractions have been removed. The only people potentially broken by this change are those injecting IClock into their own code or trying to inject their own IClock into our components for some reason.

The K8 code was using ISystemClock from Microsoft.Extensions. There are breaking public API changes there to replace it.

The SDK update broke some asserts in the telemetry consumers that I've commented out. Miha will fix these later.

[Tratcher]

Note to self, offline feedback from Miha.

I think the issue is in the test time provider.
You're returning TimeSpan ticks from GetTimestamp, but the frequency is still set to Stopwatch.Frequency.
You can either override TimestampFrequency and return TimeSpan.TicksPerSecond, or return (long)(_currentTime.TotalSeconds * TimestampFrequency) from GetTimestamp.
Or use some random frequency number that's different from TimeSpan/Stopwatch so that our tests don't accidentally work.
The frequency of Stopwatch on Unix is in nanoseconds, while TimeSpan ticks are 100-nanoseconds

[sebastienros]

Is this expected that the variable is named _period but it's used on the dueTime argument?
So it will be executed once, delayed, and not periodically.

public bool Change (int dueTime, int period);

[Tratcher]

It re-starts itself after running the current callback.

reverse-proxy/src/ReverseProxy/Health/EntityActionScheduler.cs

Line 238 in 4868c55

entry.SetTimer();

[sebastienros]

This PR has nothing to do with this, but I have to say that I find it a weird way to handle fake time. I would just expect the timer to call Advance and have the callbacks be triggers automatically, not the test to explicitly invoke the callback.

[MihaZupan]

Do we know when the built-in test time provider will ship, such that we can remove this one?

[sebastienros]

Left two comments but I assume you will have an answer and nothing to change

[MihaZupan]

Looks good, thanks!

[MihaZupan]

Suggested change

	public override long TimestampFrequency => TimeSpan.TicksPerSecond;
	public override long TimestampFrequency => TimeSpan.TicksPerSecond * 7;

Nit: Can we have this return a non-standard value, so that we can catch product errors that our tests would be happy with (e.g. we offset a timestamp by timeSpan.Ticks somewhere instead of going through TimeProvider)?
TimestampFrequency and GetTimestamp are the only places that should have to change.

[MihaZupan]

Suggested change

	public override long GetTimestamp() => _currentTime.Ticks;
	public override long GetTimestamp() => _currentTime.Ticks * 7;