Fix BlockingHttp4sServlet handling requests asynchronously (0.21)

[nigredo-tori]

See #2939, #2941.

Closes #2939.

[nigredo-tori]

[info] Blaze Http1Client should
...
[error]   x reset request timeout (1 second, 32 ms)
[error]    an exception was thrown Request timeout after 1000 ms (BlazeClientSpec.scala:252)
[error] org.http4s.client.blaze.BlazeClientSpec.$anonfun$new$62(BlazeClientSpec.scala:252)

Interesting. This doesn't look related to this PR, unless I've somehow messed up one of the test threadpools - which is definitely possible. That .evalTap looks wrong to me now - the write is not shifted to blocker, so it happens on the ContextShift - which could explain this.

I'll try and fix this a couple hours later - both here and in 0.20.

[rossabaker]

It is probably unrelated. We've had flaky blaze tests like this one on Travis for a very long time and not been able to get to the bottom of it. It's also slow to troubleshoot, because it doesn't happen locally. I think it's related to too many unsafeRunSync()s in the tests temporarily locking up the more limited resources of the CI environment. We need to make better use of the async testing features introduced in later specs2.

[rossabaker]

@nigredo-tori Is the evalTap issue serious enough to delay releasing 0.20.13? We have several other bugfixes people are waiting on, but we can wait a few hours. Otherwise, we can release again real soon.

[nigredo-tori]

Is the evalTap issue serious enough to delay releasing 0.20.13?

There's definitely a deadlock possible there in some cases (e.g. in tests if the client is running on the same ContextShift). But it doesn't look like anyone but me is using the blocking servlet, so it's not a blocker (no pun intended).

At any rate, I've fixed this here, and sent a PR against series/0.20 (#2957).

[rossabaker]

This was handled in the merge from series/0.20.