test: some integration tests fail when using simulated time

[jmarantz]

It's not clear if these are all due to the same issue or not.

e.g.
test/integration:filter_manager_integration_test hangs when run under sim-time.

[jmarantz]

This blocks #4160

[jmarantz]

with #10551 , test/extensions/filters/http/cache:cache_filter_integration_test passes consistently, but only with a real-time polling delay of 50ms (+ or -) which I believe should not be necessary.

[jmarantz]

More details on the cache_filter_integration_test.

[ RUN      ] Protocols/CacheIntegrationTest.GetRequestWithBodyAndTrailers/IPv4_HttpDownstream_HttpUpstream
test/extensions/filters/http/cache/cache_filter_integration_test.cc:115: Failure
Value of: response->headers()
Expected: is a superset of headers:
':status', '200'
'date', 'Thu, 01 Jan 1970 01:00:00 GMT'
'cache-control', 'public,max-age=3600'
'content-length', '42'

  Actual: 16-byte object <D8-A7 9C-04 00-00 00-00 78-AF 9C-04 00-00 00-00> (of type Envoy::Http::ResponseHeaderMap), where the following matchers don't match any elements:
matcher #1: is equal to ("date", "Thu, 01 Jan 1970 01:00:00 GMT")
Stack trace:
  0x1dc9846: Envoy::Extensions::HttpFilters::Cache::CacheIntegrationTest_GetRequestWithBodyAndTrailers_Test::TestBody()
  0x48c6a74: testing::internal::HandleSehExceptionsInMethodIfSupported<>()
  0x48b74cb: testing::internal::HandleExceptionsInMethodIfSupported<>()
  0x48a4d93: testing::Test::Run()
  0x48a5757: testing::TestInfo::Run()
... Google Test internal frames ...

[  FAILED  ] Protocols/CacheIntegrationTest.GetRequestWithBodyAndTrailers/IPv4_HttpDownstream_HttpUpstream, where GetParam() = 12-byte object <00-00 00-00 00-00 00-00 00-00 00-00> (365 ms)

The code in question is here:

    response->waitForEndStream();
    EXPECT_TRUE(response->complete());
    EXPECT_THAT(response->headers(), IsSupersetOfHeaders(response_headers));

It appears to me that response->headers() is populated, or at least std::moved in the main thread, so I am not understanding how there can be a race here, but adding the real-time delay appears to be needed.