We now have a (well, two, depending on AES hardware support) universal
cipher suite preference order, based on their security and performance.
Peer and application lists are now treated as filters (and AES hardware
support hints) that are applied to this universal order.

This removes a complex and nuanced decision from the application's
responsibilities, one which we are better equipped to make and which
applications usually don't need to have an opinion about. It also lets
us worry less about what suites we support or enable, because we can be
confident that bad ones won't be selected over good ones.

This also moves 3DES suites to InsecureCipherSuites(), even if they are
not disabled by default. Just because we can keep them as a last resort
it doesn't mean they are secure. Thankfully we had not promised that
Insecure means disabled by default.

Notable test changes:

  - TestCipherSuiteCertPreferenceECDSA was testing that we'd pick the
    right certificate regardless of CipherSuite ordering, which is now
    completely ignored, as tested by TestCipherSuitePreference. Removed.

  - The openssl command of TestHandshakeServerExportKeyingMaterial was
    broken for TLS 1.0 in CL 262857, but its golden file was not
    regenerated, so the test kept passing. It now broke because the
    selected suite from the ones in the golden file changed.

  - In TestAESCipherReordering, "server strongly prefers AES-GCM" is
    removed because there is no way for a server to express a strong
    preference anymore; "client prefers AES-GCM and AES-CBC over ChaCha"
    switched to ChaCha20 when the server lacks AES hardware; and finally
    "client supports multiple AES-GCM" changed to always prefer AES-128
    per the universal preference list.

    * this is going back on an explicit decision from CL 262857, and
      while that client order is weird and does suggest a strong dislike
      for ChaCha20, we have a strong dislike for software AES, so it
      didn't feel worth making the logic more complex

  - All Client-* golden files had to be regenerated because the
    ClientHello cipher suites have changed.
    (Even when Config.CipherSuites was limited to one suite, the TLS 1.3
    default order changed.)

Fixes #45430
Fixes #41476 (as 3DES is now always the last resort)

Change-Id: If5f5d356c0f8d1f1c7542fb06644a478d6bad1e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/314609


Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>