Add SSL to redbean

Your redbean can now interoperate with clients that require TLS crypto.
This is accomplished using a protocol polyglot that lets us distinguish
between HTTP and HTTPS regardless of the port number. Certificates will
be generated automatically, if none are supplied by the user. Footprint
increases by only a few hundred kb so redbean in MODY=tiny is now 1.0mb

- Add lseek() polyfills for ZIP executable
- Automatically polyfill /tmp/FOO paths on NT
- Fix readdir() / ftw() / nftw() bugs on Windows
- Introduce -B flag for slower SSL that's stronger
- Remove mbedtls features Cosmopolitan doesn't need
- Have base64 decoder support the uri-safe alternative
- Remove Truncated HMAC because it's forbidden by the IETF
- Add all the mbedtls test suites and make them go 3x faster
- Support opendir() / readdir() / closedir() on ZIP executable
- Use Everest for ECDHE-ECDSA because it's so good it's so good
- Add tinier implementation of sha1 since it's not worth the rom
- Add chi-square monte-carlo mean correlation tests for getrandom()
- Source entropy on Windows from the proper interface everyone uses

We're continuing to outperform NGINX and other servers on raw message
throughput. Using SSL means that instead of 1,000,000 qps you can get
around 300,000 qps. However redbean isn't as fast as NGINX yet at SSL
handshakes, since redbean can do 2,627 per second and NGINX does 4.3k

Right now, the SSL UX story works best if you give your redbean a key
signing key since that can be easily generated by openssl using a one
liner then redbean will do all the things that are impossibly hard to
do like signing ecdsa and rsa certificates that'll work in chrome. We
should integrate the let's encrypt acme protocol in the future.

Live Demo: https://redbean.justine.lol/
Root Cert: https://redbean.justine.lol/redbean1.crt

third_party/mbedtls/dhm.h

@@ -1,76 +1,8 @@
-/* clang-format off */
-
-/**
- * \file dhm.h
- *
- * \brief   This file contains Diffie-Hellman-Merkle (DHM) key exchange
- *          definitions and functions.
- *
- * Diffie-Hellman-Merkle (DHM) key exchange is defined in
- * <em>RFC-2631: Diffie-Hellman Key Agreement Method</em> and
- * <em>Public-Key Cryptography Standards (PKCS) #3: Diffie
- * Hellman Key Agreement Standard</em>.
- *
- * <em>RFC-3526: More Modular Exponential (MODP) Diffie-Hellman groups for
- * Internet Key Exchange (IKE)</em> defines a number of standardized
- * Diffie-Hellman groups for IKE.
- *
- * <em>RFC-5114: Additional Diffie-Hellman Groups for Use with IETF
- * Standards</em> defines a number of standardized Diffie-Hellman
- * groups that can be used.
- *
- * \warning  The security of the DHM key exchange relies on the proper choice
- *           of prime modulus - optimally, it should be a safe prime. The usage
- *           of non-safe primes both decreases the difficulty of the underlying
- *           discrete logarithm problem and can lead to small subgroup attacks
- *           leaking private exponent bits when invalid public keys are used
- *           and not detected. This is especially relevant if the same DHM
- *           parameters are reused for multiple key exchanges as in static DHM,
- *           while the criticality of small-subgroup attacks is lower for
- *           ephemeral DHM.
- *
- * \warning  For performance reasons, the code does neither perform primality
- *           nor safe primality tests, nor the expensive checks for invalid
- *           subgroups. Moreover, even if these were performed, non-standardized
- *           primes cannot be trusted because of the possibility of backdoors
- *           that can't be effectively checked for.
- *
- * \warning  Diffie-Hellman-Merkle is therefore a security risk when not using
- *           standardized primes generated using a trustworthy ("nothing up
- *           my sleeve") method, such as the RFC 3526 / 7919 primes. In the TLS
- *           protocol, DH parameters need to be negotiated, so using the default
- *           primes systematically is not always an option. If possible, use
- *           Elliptic Curve Diffie-Hellman (ECDH), which has better performance,
- *           and for which the TLS protocol mandates the use of standard
- *           parameters.
- *
- */
-/*
- *  Copyright The Mbed TLS Contributors
- *  SPDX-License-Identifier: Apache-2.0
- *
- *  Licensed under the Apache License, Version 2.0 (the "License"); you may
- *  not use this file except in compliance with the License.
- *  You may obtain a copy of the License at
- *
- *  http://www.apache.org/licenses/LICENSE-2.0
- *
- *  Unless required by applicable law or agreed to in writing, software
- *  distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
- *  WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- *  See the License for the specific language governing permissions and
- *  limitations under the License.
- */
-
 #ifndef MBEDTLS_DHM_H
 #define MBEDTLS_DHM_H
-
-#if !defined(MBEDTLS_CONFIG_FILE)
-#include "third_party/mbedtls/config.h"
-#else
-#include MBEDTLS_CONFIG_FILE
-#endif
 #include "third_party/mbedtls/bignum.h"
+#include "third_party/mbedtls/config.h"
+/* clang-format off */
 
 /*
  * DHM Error codes