Native parse_url accepts URLs and registry-based hosts that java.net.URI treats differently #7330

Describe the bug

Native parse_url (and try_parse_url) runs by default (CometParseUrl is Compatible), but it accepts some URLs that Spark's java.net.URI treats differently, so Comet and Spark return different results.

Spark builds new URI(url) (ParseUrl in 3.5, UrlExpressionEvalUtils.getUrl in 4.x). On URISyntaxException it returns NULL, or raises INVALID_URL when failOnError (ANSI) is set, and HOST is URI.getHost. Comet's native path validates only spaces, {, }, <, > and control characters (has_invalid_uri_chars), then splits the URL with the RFC 3986 Appendix B regex. extract_host takes whatever follows the last @ in the authority.

Steps to reproduce

java.net.URI on JDK 17 for each input (local probe):

SELECT parse_url('http://a_b.com/p', 'HOST'),
       parse_url('http://u@v@h/p', 'HOST'),
       parse_url('http://h/%zz', 'PATH'),
       parse_url('http://h/p#a#b', 'PATH');

The query needs to read the URLs from a table (or disable constant folding) for the expression to reach Comet.

Expected behavior

The same results as Spark: a null host for registry-based authorities, and NULL (or INVALID_URL under ANSI) for URLs that java.net.URI rejects, such as invalid % escapes and a second #. USERINFO of a registry-based authority may need the same check, since URI.getUserInfo is null there too.

Additional context

Found while reviewing #7329, which does not change this behavior: its new HTTP fast path matches the existing regex decomposition, so the gap is on main already. The current parse_url.sql fixtures use only well-formed URLs, so none of these inputs is covered.

cc @sunchao