pool: add firefly onStart marker for MoverProtocol-based transfers

[ShawnMcKee]

Problem

AbstractMoverProtocolTransferService, the base class for MoverProtocol-based transfer services (used by RemoteHttpTransferService for FTS third-party copy movers), never calls transferLifeCycle.onStart(). This means firefly flow-start UDP markers are never emitted for TPC movers, even though:

• DefaultPostTransferService correctly sends onEnd() markers (using the deriveLocalEndpoint() fallback added in 11.2.3)
• NettyTransferService (direct client connections via xrootd/HTTP) correctly calls onStart() in its executeMover() method

Impact

ESnet Stardust dashboards show incomplete flow information for TPC transfers. Specifically:

• TPC onEnd markers are present with correct experiment/activity IDs from transfer tags (e.g., activityId=11, 15, 16 for ATLAS categories)
• Zero TPC onStart markers are emitted from pool nodes for TPC transfers
• Direct-read onStart markers (from NettyTransferService) are present but use FQAN fallback (activityId=1) since worker nodes don't send SciTag headers

Evidence from ATLAS AGLT2 pool logs:

# 194 TPC end markers with correct transfer-tag classifier
scitags event=marker state=end protocol=remotehttpsdatatransfer ... transferTag=143 experimentId=2 activityId=15 classifier=transfer-tag

# 0 TPC start markers
grep -c 'protocol=remote.*state=start' → 0

# 141 direct-read start markers, all FQAN/activityId=1
scitags event=marker state=start protocol=https ... experimentId=2 activityId=1 classifier=fqan

Fix

Add a startTransferLifeCycle() call in MoverTask.run() (before I/O begins) that:

1. Checks _transferLifeCycle is configured and protocol is IP-based
2. Derives the local endpoint from the remote address using NetworkUtils.getLocalAddress() — the same approach used by DefaultPostTransferService.deriveLocalEndpoint() for onEnd
3. Calls transferLifeCycle.onStart() with the remote endpoint, derived local endpoint, protocol info, and subject
4. Handles SocketException gracefully with debug logging

This mirrors the pattern already established in NettyTransferService.executeMover() for direct connections, extending it to all MoverProtocol-based transfers.

Testing

• Compilation verified (mvn -pl modules/dcache -am compile -DskipTests)
• Consistent with existing patterns in NettyTransferService and DefaultPostTransferService

Signed-off-by: Shawn McKee smckee@umich.edu

[kofemann]

I think that suggested change is wrong. It might preserve the pool IP, but (a) uses the wrong port and (b) will work incorrectly on multi-home hosts.

I would suggest updating the RemoteHttpTransferService and passing the TransferLifeCycle to the mover when it is created by the createMoverProtocol method. The RemoteHttpDataTransferProtocol#doGet then should call onStart as soon as the local endpoint is defined.