Add RTI-driven transient federate launch and SST session key refresh

[kushalpaliwal01]

Summary

This PR extends the transient federate and SST secure communication support in reactor-c with two new capabilities: RTI-driven transient federate launching and runtime SST session key refresh. Together these allow a federation to dynamically manage transient federates and rotate security credentials without any manual intervention from within the LF program.

---

1. RTI-driven transient federate launch

Motivation

Previously, launching a transient federate required the LF program itself to construct and execute a shell command inside a reaction — with hardcoded binary paths, federation IDs, and SST config paths. This was fragile, not portable to remote deployments, and put infrastructure concerns inside application logic. This PR moves transient federate launching entirely into the RTI.

Configuration

At startup the RTI accepts a new -tf <path> command-line argument pointing to a transient_federates.config file. This file is generated at compile time by the LF compiler and lists every transient federate in the federation. Each entry describes the federate's ID, name, IP address, SSH user, binary launch path, and SST config path. The RTI parses this file once during initialization and stores the launch details in each transient federate's federate_info_t struct, so they are immediately available when a launch request arrives.

API

A persistent federate calls lf_launch_transient_federate(port_name) from within a reaction, passing the name of the output port connected to the transient federate it wants to launch. The runtime looks up that port name in a compile-time-generated mapping (_fed.port_to_transient_feds_mapping) that associates each output port with the IDs of the transient downstream federates connected to it. The IDs of the transients to be launched are queued in pending_transient_launches and the atomic flag transient_launch_requested is set.

Protocol

The actual message to the RTI is not sent immediately from within the reaction. Instead, it is sent piggyback the next time the federate calls lf_send_tagged_message() — the runtime checks transient_launch_requested and for each queued federate ID sends a MSG_TYPE_TRANSIENT_LAUNCH_REQUEST message to the RTI. The message carries the 2-byte ID of the transient federate to launch.

When the RTI receives a MSG_TYPE_TRANSIENT_LAUNCH_REQUEST it reads the federate ID, looks up the pre-parsed launch details for that federate, and constructs a launch command. If the transient is on the same machine as the
RTI, it runs the binary directly with nohup so it survives the parent process. If the transient is on a remote machine, the RTI opens an SSH connection to the target host and runs the binary there in the background. In both cases the federate binary is started with its federation ID and SST config path as arguments. Once launched, the transient federate connects to the RTI through the normal transient connection protocol.

---

2. SST session key refresh

Motivation

In long-running federations, rotating SST session keys periodically is important for security. This PR adds a runtime API that lets a persistent federate trigger a key refresh from within a reaction without blocking or disrupting the federation's execution.

API and flow

A persistent federate calls lf_refresh_key() from within a reaction. This sets the atomic flag rekey_requested and returns immediately — no blocking, no network I/O inside the reaction. The next time that federate sends a tagged message via lf_send_tagged_message(), the runtime checks rekey_requested and calls _lf_check_and_perform_rekey(). This sends a MSG_TYPE_SST_KEY_REFRESH_REQUEST message to the RTI along with the current key ID. The RTI handles the request in handle_key_refresh_request(), coordinates the new key establishment with the SST security context, and
responds with MSG_TYPE_SST_KEY_ACK to confirm the refresh is complete.

---

Network abstraction migration for transient federates

Several code paths in the RTI responsible for handling transient federate connection, disconnection, and messaging were still using raw socket operations instead of the network abstraction layer. This caused SST communication to fail for transient federates because SST requires all reads and writes to go through the abstraction layer. The affected paths — including upstream connected and disconnected notifications, start tag delivery, stop requests, and the transient connection acceptance loop — have all been updated to use the network abstraction layer consistently. Transient federates now communicate correctly regardless of whether the underlying transport is TCP, SST, or TLS.

---

Hot swap fix

Fixed a bug in receive_and_check_fed_id_message where a transient federate attempting a hot swap was incorrectly rejected by the RTI. The hot swap scenario — where a transient reconnects while its previous instance is still
running, during the execution phase, with no other hot swap already in progress — was hitting an early return -1 before reaching the hot swap initialization block. This meant hot_swap_federate was never allocated and hot_swap_in_progress was never set, causing the RTI to treat the reconnecting instance as a duplicate and close the connection. The early return has been removed so the code correctly falls through to the hot swap logic.