Remove self-imposed limit on max concurrent streams if the server doesn't impose any.

[MakMukhi]

No description provided.

[dfawley]

This seems fishy to me. But not so much this as our settings handling in general.

It seems the way it works right now, we aren't applying any settings until right as we send the ack. This will result in a race if I'm understanding it correctly:

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.

I think 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. And...since it's possible for one setting to become more permissive while another becomes less permissive, we probably need to hold a lock, apply the settings, queue the ack, and then release the lock.

[dfawley]

This doesn't make the existing problem any worse, so we should merge it now.