crypto/tls: reject duplicate TLS 1.3 EncryptedExtensions

When a TLS 1.3 client processes the server's encryptedExtensionsMsg it
should reject instances that contain duplicate extension types.

RFC 8446 §4.2 says:
  There MUST NOT be more than one extension of the same type in a given
  extension block.

This update matches enforcement done in the client hello unmarshalling,
but applied to the TLS 1.3 encrypted extensions message unmarshalling.

Making this change also allows enabling the
DuplicateExtensionClient-TLS-TLS13 BoGo test.

Updates #72006

Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/673757
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>

Author: cpu

handshake_messages.go

@@ -1100,6 +1100,7 @@ func (m *encryptedExtensionsMsg) unmarshal(data []byte) bool {
 		return false
 	}
 
+	seenExts := make(map[uint16]bool)
 	for !extensions.Empty() {
 		var extension uint16
 		var extData cryptobyte.String
@@ -1108,6 +1109,11 @@ func (m *encryptedExtensionsMsg) unmarshal(data []byte) bool {
 			return false
 		}
 
+		if seenExts[extension] {
+			return false
+		}
+		seenExts[extension] = true
+
 		switch extension {
 		case extensionALPN:
 			var protoList cryptobyte.String