Ember server graceful shutdown

[RaasAhsan]

Closes #3067. The goal of this PR is to give ember-server a graceful shutdown sequence, which @rossabaker captures succinctly in the original issue. I'd still like to add tests and follow up with some fs2 questions, but I think it's ready for review.

[RaasAhsan]

Separately, I'm looking into improving the performance of parJoin and getting rid of this prefetch altogether, but if we're not OK with a slight performance hit we can hold this PR

[RaasAhsan]

For some reason the server isn't immediately connect-able to after the resource is acquired. I wonder if there's some detail in the NIO API about this, but I have to wait 3 seconds or else I get a Connection refused, which seems to imply that the server socket channel hasn't even been opened yet?

[RaasAhsan]

You'll notice that I didn't actually include any tests for the graceful shutdown mechanism... Unsurprisingly that behavior is rather hard to exercise since there's a lot of nondeterministic elements to it. In particular, we can't deterministically start a request after the server socket channel has been closed.

[rossabaker]

I think we could batter it with requests and assert that every request either completed successfully or was refused a connection. But our CI is suffering enough as it is.

[ChristopherDavenport]

I got this feedback recently could this be integrated, @djspiewak believe this will also speed up so may cancel out the prefetch costs.

.parJoin(maxConcurrency)
          .interruptWhen(terminationSignal)
          .drain)

to

          .flatMap(s => Stream.resource(s.compile.resource.drain.background))
          .interruptWhen(terminationSignal)
          .drain)

[RaasAhsan]

Does that have the semantics we want? It seems like it's going to start the handler for every socket in a separate fiber, lift that resource into stream, then immediately exit which cancels the fiber (since it introduced a scope). I think resourceWeak would work but then we are possibly leaking fibers, and we also can't control concurrency. Let me know if I'm wrong about that though

Also I realized that the prefetch isn't that bad. It becomes a problem when you have a lot of connection cycling, but it shouldn't affect max RPS all else being equal

[RaasAhsan]

Removed the comment I added about prefetch, because it really only limits the rate at which connections are accepted, but not max RPS. I'm going to write a special-purpose combinator that mixes the semantics of parJoin, prefetch and drain since they come with a lot of baggage in a follow up, so if you're OK with that, this is pretty much ready :)

[ChristopherDavenport]

I think this seems good.