datetime.time service is missing the request stack in kernel tests

Did some archeology and this was actually removed in https://git.drupalcode.org/project/drupal/-/commit/8a034cda9b0508913e8ee... during development in #3113971: Replace REQUEST_TIME in services but I can't find any actual discussion.

Note that if people are turned off by the modifying of the request object in the example code in the issue summary, note that we currently do not have a generic, mutable version of the time service that could be used in tests, so this seems to be the most straightforward way to achieve that as far as I can tell.

Added a quick MR. Verified that this fixed a test as described in the issue summary. Didn't add an explicit test as that seems somewhat esoteric to me, but could be easily added in KernelTestBaseTest::testRegister() if deemed appropriate.

Yeah, haven't looked into it yet. Will try to fix them and then we can evaluate if this is actually a problematic change or if the tests that are now failing are just problematic.

So I figured out what was going wrong in ResourceObjectNormalizerCacherTest. The incrementing of the request time was not done correctly as it is inherently additive, i.e. what the code did was:

$requestTime = getRequestTime();
$requestTime += 500;
$requestTime += 800; // This is now 1300 more than originally!
$requestTime += 801; // This is now 2101 more than originally!

But the assertions and code comments were doing:

// Test with initial request time
// Test with initial request time + 500
// Test with initial request time + 800
// Test with initial request time + 801

The fact that the test passed nevertheless was due to the very bug being fixed here. The "current time" in the memory backend never actually got updated so the MemoryBackend::prepareItem() never actually marked the items as invalid. And then the supposed "+800" test (which is actually a "+1300" test) accidentally tests the same code path that the supposed "+801 test" test should be testing. That one doesn't really make sense, though, anyway. When a cache item is expired it should not be returned, so the max age should not continuously be 0, instead it should be back to 800 because a new cache item was generated.

I think that the fact that the only test that failed was actually failing precisely due to this bug (and some flawed assumptions) is a pretty good case that this is in fact a valid bug fix.

Oh right, forgot to point that out. I realized that whatever happens in KernelTestBase::register() only acts as overrides of stuff in core.services.yml and with the added argument the definitions are the same so we might as well drop the entire override.

As pointed out in the issue summary, the Git history is not very informative about why in particular this was added in the first place, so since tests pass without it, I think the most reasonable way forward is to just delete it.