Just allocate what's needed for SSL write buffers.

When we refactored all the buffering logic, we retained upstream
OpenSSL's allocation patterns. In particular, we always allocated fixed
size write buffer, even though, unlike when reading, we trivially know a
tighter bound (namely however much we happen to be writing right now).

Since the cutoff for when Windows' malloc starts having a hard time is
just below the TLS maximum record size, do the more natural thing of
allocating what we need to hold outgoing ciphertext.

(This only does anything to the write half. Read half is a bit more
involved.)

BUG=chromium:524258

Change-Id: I0165f9ce822b9cc413f3c77e269e6154160537a7
Reviewed-on: https://boringssl-review.googlesource.com/14405
Reviewed-by: Steven Valdez <svaldez@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>

ssl/ssl_buffer.c

@@ -225,26 +225,7 @@ int ssl_write_buffer_init(SSL *ssl, uint8_t **out_ptr, size_t max_len) {
     return 0;
   }
 
-  size_t header_len = ssl_seal_align_prefix_len(ssl);
-
-  /* TODO(davidben): This matches the original behavior in keeping the malloc
-   * size consistent. Does this matter? |cap| could just be |max_len|. */
-  size_t cap = SSL3_RT_MAX_PLAIN_LENGTH + SSL3_RT_SEND_MAX_ENCRYPTED_OVERHEAD;
-  if (SSL_is_dtls(ssl)) {
-    cap += DTLS1_RT_HEADER_LENGTH;
-  } else {
-    cap += SSL3_RT_HEADER_LENGTH;
-    if (ssl->mode & SSL_MODE_CBC_RECORD_SPLITTING) {
-      cap += SSL3_RT_HEADER_LENGTH + SSL3_RT_SEND_MAX_ENCRYPTED_OVERHEAD;
-    }
-  }
-
-  if (max_len > cap) {
-    OPENSSL_PUT_ERROR(SSL, SSL_R_BUFFER_TOO_SMALL);
-    return 0;
-  }
-
-  if (!setup_buffer(buf, header_len, cap)) {
+  if (!setup_buffer(buf, ssl_seal_align_prefix_len(ssl), max_len)) {
     return 0;
   }
   *out_ptr = buf->buf + buf->offset;