Race in applying settings and acking

[dfawley]

The way it works right now, we aren't applying any settings until right as we send the ack. This can result in a race:

1. Server and client are in steady state with maximum streams = 5
2. Client receives a settings frame with a limit of 1. It appends the ack to the control buffer in response.
3. Client initiates 5 new streams and pushes their headers onto the control buffer, which it thinks is fine because the settings are not applied yet.
4. Client applies settings and sends settings ack, promising not to initiate more than one stream.
5. Client sends headers for 5 new streams.

We need to make sure settings are applied before queuing the ack message if the settings are more restrictive than they were before. On the other hand, we should queue the ack message and then apply the settings if they are more permissive.