Remove configuration reload action in cardano-rpc server startup

[carbolymer]

Changelog

- description: |
    Remove configuration reload action in cardano-rpc server startup
# uncomment types applicable to the change:
  type:
  # - feature        # introduces a new feature
   - breaking       # the API has changed in a breaking way
  # - compatible     # the API has changed but is non-breaking
  # - optimisation   # measurable performance improvements
   - refactoring    # QoL changes
  # - bugfix         # fixes a defect
  # - test           # fixes/modifies tests
  # - maintenance    # not directly related to the code
  # - release        # related to a new release preparation
  # - documentation  # change in code docs, haddocks...
# uncomment at least one main project this PR is associated with
  projects:
  # - cardano-api
  # - cardano-api-gen
   - cardano-rpc
  # - cardano-wasm

Context

This is not needed anymore, as configuration reload is implemented as whole server restart:

• WIP: gRPC: Reload configuration on SIGHUP cardano-node#6468

Checklist

• Commit sequence broadly makes sense and commits have useful messages
• New tests are added if needed and existing tests are updated. See Running tests for more details
• Self-reviewed the diff

[Copilot]

Pull request overview

Removes the configuration reload action from cardano-rpc server startup, switching runRpcServer to accept a preloaded (RpcConfig, NetworkMagic) since reload is now handled via full server restart.

Changes:

• Update runRpcServer signature to take (RpcConfig, NetworkMagic) instead of an IO reload action.
• Inline destructuring of the configuration tuple in runRpcServer.
• Remove outdated TODO/comment about logging on config reload.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

This changes runRpcServer from taking an IO action to taking a pure (RpcConfig, NetworkMagic) value, which is an API-breaking change for any existing call sites. If the project expects this function to remain stable for external/internal consumers, consider keeping a backward-compatible wrapper (e.g., runRpcServerWithReload :: Tracer IO TraceRpc -> IO (RpcConfig, NetworkMagic) -> IO ()) that calls the new runRpcServer after loading once.

[Copilot]

The parameter name rpcConfig is misleading now that it holds a tuple (RpcConfig, NetworkMagic) (it’s not just the RpcConfig). Renaming it to something like rpcCfgAndMagic / rpcConfigAndMagic (or destructuring in the argument list) would make the code easier to read and reduce confusion.