[TLS] Separate APIs for 0-RTT

[Eric Rescorla <[e-mail]>]

The current text says:

   0-RTT data has very different security properties from data
   transmitted after a completed handshake: it can be replayed.
   Implementations SHOULD provide different functions for reading and
   writing 0-RTT data and data transmitted after the handshake, and
   SHOULD NOT automatically resend 0-RTT data if it is rejected by the
   server.

I think the second piece of guidance (about automatic re-send) is still
good but it seems like implementations are mostly converging on a single
API. Of the implementations I know, NSS, BoringSSL (I think), and Mint have
a single API and OpenSSL's use of two APIs is an outlier. I don't think
it's helpful to have a SHOULD that a lot of people violate, especially when
this also indicates we don't have consensus on this SHOULD.

I propose we remove this recommendation in favor of one which simply says
that implementations should need applications to opt-in to 0-RTT. That
would allow implementations to have either API.

-Ekr