KTOR-2021 Add GMTClock

[hfhbd]

trafficstars

Subsystem Server, Client Core

Motivation

• Add a mockable Clock Clock for mocking time: https://youtrack.jetbrains.com/issue/KTOR-2021

Status

• [x] Compiling
• [ ] Tests: Use TestTimeSource() via TestScope to provide a GMTClock to the new needed parameter. When coroutines 1.6.0 is merged, and https://youtrack.jetbrains.com/issue/KTOR-3571 is implemented, the testTimeSource from runTest can be used.
• [ ] APIDump

Next Steps

• Refactor all tests to support delay skipping runTest via testTimeSource.toClock()

[hfhbd]

@rsinukov Hey Rustam, because this PR is quite large, before fixing all test code, could you provide some feedback regarding the main changes (GMTDate, GMTClock, Environment and HttpResponse)? :)

[rsinukov]

HI @hfhbd Is there a reason why we may need multiple clocks in the application? If not, we can use a service loader or some similar pattern to provide a single clock to different parts of the app. This will make PR less invasive and easier to upgrade to kotlinx.datetime in the future.

[hfhbd]

@rsinukov For the user, there are only "2" clocks needed:

@Test
fun testing() = runTest {
    val testClock = testTimeSource.toGMTClock()
    val server = embeddedServer(CIO) {
        environment.clock = testClock
    }
    val client = HttpClient(io.ktor.client.engine.cio.CIO) {
        engine {
            clock = testClock
        }
    }
   // to something with client and server having a mocked clock
  testTimeSource += 10.seconds
}

In ktor code basis, I often needed to add the clock as a parameter, because WeakTimeQueue needs its own clock, see also https://youtrack.jetbrains.com/issue/KTOR-3658. Otherwise, internal client.engine.clock/environment.config.clock is used (if possible). But of course, we could switch to some kind of dependency injection/service loader.

[e5l]

Hey @hfhbd, thanks for the contribution. We prefer to migrate to kotlinx.datetime clock instead

[hfhbd]

So it's stable now? :D https://github.com/ktorio/ktor/pull/2750#issuecomment-999404419

[e5l]

Nope, but we have a clear estimate

[hfhbd]

So you want to implement it or should I rebase it and merge it with #2750?

[e5l]

Let's merge it with #2750. Could you help me with that?

[hfhbd]

Sure