Download URL pattern not compatible with corporate environment with long DNS TLDs

Consider a corporate environment that meet the following criteria:

• Internal DNS root with private top level domain (TLD) producing such DNS FQDN: https://foobar.abcdefg.vwxyz/ (TLD vwxyz is 5 characters long)
• The corporate IT infrastructure is configured (e.g. via /etc/resolv.conf) with DNS search suffix .vwxyz, so that users are only exposed to the "shorter" DNS names such as https://foobar.abcdefg/ (the OS automatically adds .vwxyz suffix as foobar.abcdefg.vwxyz is a valid DNS entry). The corporate private X.509 infrastructure also delivers certificates designed with these short names in mind (in case there is any concern regarding certificate validation).
• Build tools (e.g. Gradle) configured to use a corporate repository manager (i.e. Sonatype Nexus Repository Manager, JFrog Artifactory, etc.) on such internal URL https://artifacts.abcdefg/ (note the absence of .vwxyz as we rely on DNS search suffix), instead of Sonatype Central

With the above, the "apparent TLD" to users/build tools for artifact URLs is abcdefg (7 characters) instead of vwxyz (5 characters).

This does not match the URL pattern at https://github.com/spdx/spdx-java-model-2_X/blob/f5e55bded417f7ad5a77500702b7aca0df332dd8/src/main/java/org/spdx/library/model/v2/SpdxConstantsCompatV2.java#L367 as it restricts the TLD to be 5 characters at most .[a-z]{2,5}, even though URLs are valid within the corporate environment. This causes SPDX URL checks (such as when using the Gradle SPDX plugin) to fail.

Start in src/main/java/org/spdx/library/model/v2/SpdxConstantsCompatV2.java around line 367, where the URL pattern is defined, and inspect any tests covering SPDX URL validation. Reproduce the failure with a URL such as https://artifacts.abcdefg/ and update the validation behavior so valid corporate URLs are accepted. Confirm existing URL checks still pass.