Properly support HTTP/1.1 with non-http scheme absolute-uri and empty Host header

Nobody has claimed this yet.

**Jetty version(s)**
9+

**Java version/vendor** `(use: java -version)`
All

**OS type/version**
All

**Description**
In the process of investigating the `HostHeaderCustomizer` in issue #7250 and the `HostPort` implementation in issue #7269 it was discovered
that our handling of empty `Host` header is wholly invalid and introduces a side effect on HTTP/1.1 requests that causes the exposure
of internal server ip to on requests forwarded through intermediaries as identified in issue #7277

Per the HTTP/1.1 spec section on `Host`
https://datatracker.ietf.org/doc/html/rfc7230#section-5.4

```
The "Host" header field in a request provides the host and port
information from the target URI, enabling the origin server to
distinguish among resources while servicing requests for multiple
host names on a single IP address.

Host = uri-host [ ":" port ] ; Section 2.7.1

A client MUST send a Host header field in all HTTP/1.1 request
messages. If the target URI includes an authority component, then a
client MUST send a field-value for Host that is identical to that
authority component, excluding any userinfo subcomponent and its "@"
delimiter (Section 2.7.1). If the authority component is missing or
undefined for the target URI, then a client MUST send a Host header
field with an empty field-value.
```

Basically, on HTTP/1.1 the rules for the `Host` header are ...

1. a `Host` header field MUST always be present
2. if the request uri path is absolute, then the `Host` header value MUST be the same as the absolute URI authority (even empty).
3. if the request uri path is relative, then the `Host` header value MUST be a valid authority with a defined "host" portion.

If you don't satisfy those requirements, the request results in a 400 Bad Request.

We do a good job on rule 1 already.
We fail rule 2.
However the above mentioned issues show we fail on rule 3.
The same above mentioned Issues will address rules 1 and 3, but this issue needs to address rule 2 separately.

Start with the HTTP/1.1 Host rules in RFC 7230 section 5.4, then read the HostHeaderCustomizer and HostPort work referenced in issues #7250 and #7269. Trace handling of an absolute URI with a non-http scheme and an empty authority, and verify that the Host value follows the URI authority without exposing an internal server IP or incorrectly returning 400.

Written by the indexing model from the issue text.