Support configurable s2n blinding delay

[mathpal]

Problem:

s2n blinding default delays are high (can take almost 50 seconds in most cases).

Modern HTTP clients give up if the response is not received in under 10-30 seconds. Most modern websevers close the upstream connections on downstream/client timeout.
Thus, any webserver that acts as a s2n-tls-client and uses default blinding, ends up closing the upstream connection before it has a chance to see what was actually wrong with the upstream connection when blinding is being applied.

In the C library, this is easier to side-step by implementing self-service blinding (or just ignoring blinding).
In the rust interface (s2n-tls-tokio), there is no option of self-service blinding.

Solution:

Allow clients to configure a max blinding delay. I would expect that a side-channel attack would be made impractical even with a small delay (which is strictly better than having no delay by using "self-service" blinding).

• Does this change what S2N sends over the wire? No
• Does this change any public APIs? Yes, a new API might be required to configure max blinding delay.
• Which versions of TLS will this impact? all

Requirements / Acceptance Criteria:

What must a solution address in order to solve the problem? How do we know the solution is complete?

s2n-tls (rust and c) can be configured with a lower duration (3-5 seconds) of blinding delay.

I don't expect this to be a breaking change or change the current behavior in any way.

[maddeleine]

For posterity, it looks like our delay is a random value from 10-30 seconds and the original justification was to have it match somewhat with a normal TCP keep-alive timer setting. That still may be too high for some applications, but it doesn't go as high as 50 seconds.

[lrstewart]

It's possible that the 50 seconds came from the fact that shutdown used to potentially blind twice. But that hasn't been the case for a while: 7227160#diff-9ef39f857dd44706fab0fcbdafa024ca5c4a0cbe6184ffc11d68c1c7f3275f4e