gRPC: Reload configuration on SIGHUP

[carbolymer]

Description

This PR adds a configuration reloading for gRPC on SIGHUP.

Closes: #6249

Checklist

• Commit sequence broadly makes sense and commits have useful messages
• New tests are added if needed and existing tests are updated. These may include:
  • golden tests
  • property tests
  • roundtrip tests
  • integration tests
    See Runnings tests for more details
• Any changes are noted in the CHANGELOG.md for affected package
• The version bounds in .cabal files are updated
• CI passes. See note on CI. The following CI checks are required:
  • Code is linted with hlint. See .github/workflows/check-hlint.yml to get the hlint version
  • Code is formatted with stylish-haskell. See .github/workflows/stylish-haskell.yml to get the stylish-haskell version
  • Code builds on Linux, MacOS and Windows for ghc-9.6 and ghc-9.12
• Self-reviewed the diff

Note on CI

If your PR is from a fork, the necessary CI jobs won't trigger automatically for security reasons.
You will need to get someone with write privileges. Please contact IOG node developers to do this
for you.

[palas]

It all looks pretty robust. Just a couple of suggestions. The main thing is considering what happens when runRpcServer finishes somehow

[palas]

I think it is worth highlighting (if I understood correctly) that if runRpcServer:

• Exits successfully but prematurely, it will restart immediately (if this happens at set-up, for example, it will enter a loop).
• Exits with an exception, I am guessing the exception will get propagated and kill the node.

Not sure whether that is desirable or not, maybe it is worth considering having a restart limit, or an exception catching mechanism here.

Also, it may be worth logging if the rpc server restarts for some reason other than config changed, (or if it crashes if you end up catching the exceptions)

[carbolymer]

Exits with an exception, I am guessing the exception will get propagated and kill the node.
This will not happen because the async of rpc server is never joined.

it may be worth logging if the rpc server restarts for some reason other than config changed, (or if it crashes if you end up catching the exceptions)

Exception handler in cardano-rpc uses tracers to log the exception.

Exits successfully but prematurely, it will restart immediately (if this happens at set-up, for example, it will enter a loop).

Good catch. I think we should disable gRPC in such case. To avoid looping.

[palas]

Thanks, it looks good now. The only thing is it would now be good now to log that the rpc server was disabled because it terminated, as part of disableRpcServer maybe