[FLINK-40706] Recognize IPv6 unique local addresses in JarUriValidationUtils

[spuru9]

What is the purpose of the change

Inet6Address#isSiteLocalAddress() only recognizes the deprecated fec0::/10 prefix (removed by RFC 3879); it does not recognize the IPv6 Unique Local Address range fc00::/7 that replaced it. This pull request extends JarUriValidationUtils#isRestricted() to also classify fc00::/7 addresses as restricted, alongside the existing loopback, link-local, site-local, wildcard and multicast checks.

Brief change log

• JarUriValidationUtils#isRestricted now additionally checks IPv6 addresses against the fc00::/7 Unique Local Address range.
• Extended DefaultValidatorTest#testJarUriHostValidation with cases covering IPv6 ULA literals.

Verifying this change

This change added tests and can be verified as follows:

• Added unit test cases to DefaultValidatorTest#testJarUriHostValidation asserting that jarURIs resolving to IPv6 ULA addresses (e.g. fd00:ec2::254, fc00::1) are rejected.

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): no
• The public API, i.e., is any changes to the CustomResourceDescriptors: no
• Core observer or reconciler logic that is regularly executed: no

Documentation

• Does this pull request introduce a new feature? no
• If yes, how is the feature documented? not applicable

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

Generated-by: Claude Sonnet 5 (Claude Code)

[Dennis-Mircea]

Before opening new PRs in this area, could we first wrap up the ones that are already open? I'm concerned that we're building a backlog of overlapping PRs that are becoming hard to review. For example, #1188 has been open for over a month and is still in draft, and now #1214 targets the same area. On top of that, #1180 and #1186 were merged in the previous release and also touched this code.

When a fix that was just merged needs another follow-up, and then another, it suggests the scope wasn't fully assessed in the first place. Looking at this PR, I'm also not fully convinced that it addresses the IP validation scope as a whole, which makes me think that more PRs will be needed to fix the remaining cases one by one.

I don't want to discourage contributions, but this is starting to feel like an endless cycle, opening PRs for the sake of opening PRs. Instead of stabilizing this area, each incremental change brings new risks that we only discover afterwards.

I'd suggest we step back and take the time to research what actually needs to be done here, so we can address it in one well-scoped effort. If this requires a FLIP or a discussion on the mailing list, let's proceed with it and start a brainstorming process.