Improve errors for non-HTTP/2 DoH clients

[jsha]

Unbound requires HTTP/2 to serve DoH, which makes sense for performance reasons.

However, sometimes a client may be misconfigured to only send HTTP/1.1. For instance we recently ran into such a problem in Boulder: letsencrypt/boulder#7215.

When that happens, Unbound's debug logs show:

http2: session_recv from 192.168.4.146 failed, error: Received bad client magic byte string

And the client sees the connection closed abruptly with no response. In Go that looks like an EOF error. In curl it looks like:

curl: (52) Empty reply from server

It would be nice to have more detailed information on what went wrong. For instance, on Unbound's side, rather than logging about the client magic string, we could notice that the client did not send h2 as one of its ALPN protocols, and thus the client doesn't support HTTP/2.

Also, Unbound could support HTTP/1.1 handshakes to get as far as serving a HTTP 400 with an appropriate error message saying "Unbound requires HTTP/2 for DoH but client only supports HTTP/1.1."

[wcawijngaards]

Merged the patch to fix the issue. The reason that HTTP 2.0 is required is that dns over https requires at least 2.0, this is, for example, explained in RFC 8484.