Fix TransferLifeCycle SciTag boundary and FQAN fallback mapping

[ShawnMcKee]

Summary

This PR fixes three firefly marker eligibility issues in TransferLifeCycle.

1. Primary SciTag boundary bug:

• Before: valid transfer tag value 64 was rejected by <= 64 check.
• After: range validation is 64..65535 inclusive.

2. Fallback FQAN normalization bug:

• Before: fallback lookup used raw vo.getGroup() values (for example /atlas/usatlas) against plain VO keys (atlas).
• After: fallback normalizes group path by stripping a leading slash and taking the first path component.

3. Excludes semantics bug:

• Before: excludes were applied when only the source endpoint matched an excluded subnet.
• After: excludes are applied only when both source and destination endpoints match excluded subnets.

Code Changes

• modules/dcache/src/main/java/org/dcache/pool/movers/TransferLifeCycle.java
  • Fix SciTag range validation.
  • Normalize FQAN group for fallback VO mapping.
  • Require both endpoints to match pool.firefly.excludes before suppressing a marker.
• modules/dcache/src/test/java/org/dcache/pool/movers/TransferLifeCycleTest.java
  • Add regression tests for SciTag boundary and FQAN fallback behavior.
  • Add regression tests for excludes behavior (both excluded vs source-only/destination-only).

Tests

Executed:

• mvn -pl modules/dcache -am -Dtest=org.dcache.pool.movers.TransferLifeCycleTest -DfailIfNoTests=false -Dsurefire.failIfNoSpecifiedTests=false test

Result:

• Tests run: 6
• Failures: 0
• Errors: 0
• Skipped: 0

UMFS19 Runtime Verification

Verified on deployed 11.2.1 RPM runtime after replacing dcache-core jar and restarting pool domains:

• dcache@umfs19Domain_1.service active
• dcache@umfs19Domain_2.service active

Applied full excludes configuration:

• pool.firefly.excludes=10.10.0.0/16,192.41.230.0/23,192.41.236.0/23,2001:48a8:68f7:1::/50,2001:48a8:68f7:8001::/50

Installed-runtime matrix check:

• neither excluded => marker sent
• destination-only excluded => marker sent
• source-only excluded => marker sent
• both excluded => marker suppressed

Live capture verification (udp dst port 10514, 3 minutes):

• udp_packets_total=3
• non_excluded_network_payloads=3
• both_endpoints_excluded_payloads=0
• sample non-excluded src=2001:4118:1a:2c10:7ec2:55ff:fe6b:9705

This confirms markers are still emitted for transfers involving non-excluded networks while suppressing excluded-to-excluded transfers.

Operational Impact

• No mandatory end-user configuration changes are required after deploying this fix.
• Sites can keep standard pool.firefly.vo-mapping entries (temporary slash-prefixed workaround entries can be removed after upgrade).