feat: Allow updating logging verbosity dynamically at runtime

[sadhansood]

Description

This PR adds code for updating log directives to control logging verbosity dynamically at runtime through a service endpoint. The endpoint is only accessible from the localhost or from the same ip the server is listening on which prevents malicious access.

Test plan

Tested it on one of the private testnet node and confirmed to be working:

Basic Usage

// Set log level as info
curl --http0.9 -k -X POST "https://<endpoint>:9185/v1/log/directive?directive=info"

Granular Control

# Debug logs for walrus, info for everything else
curl --http0.9 -k -X POST "https://<endpoint>:9185/v1/log/directive?directive=info%2Cwalrus%3Ddebug"

---

[mlegner]

@sadhansood Thanks for adding this feature. I think we need to be pretty careful with this though: AFAICT from skimming the PR, this endpoint can currently be called by anyone without authentication. If we want to have this or other control endpoints, we should expose them on a separate port that is not exposed to the public.

[sadhansood]

@sadhansood Thanks for adding this feature. I think we need to be pretty careful with this though: AFAICT from skimming the PR, this endpoint can currently be called by anyone without authentication. If we want to have this or other control endpoints, we should expose them on a separate port that is not exposed to the public.

Thanks for the security feedback @mlegner ! You're absolutely right to be cautious. I've actually implemented a security check in the set_log_directive function that restricts access to server IP only and tested it from the node and my local machine to verify it works.The code at line 766-771 verifies the request IP matches the server's bound address:

// Check if the request is from the server's bound IP
if addr.ip() != state.rest_api_address().ip() {
    return Err(OrRejection::Err(LogDirectiveError::Unauthorized(
        "This endpoint can only be accessed from localhost or the server's own IP".to_string(),
    )));
}

This ensures only requests from the same machine can modify log levels. I've also added proper error handling with detailed error messages for any unauthorized attempts.
That said, I completely agree that a dedicated admin port would be a more robust long-term solution. I am more than happy to implement your suggested approach as a long term solution but i think this IP-based restriction sufficient for now given this is primarily used for debugging/operational purposes and would be pretty useful for debugging node issues?

[mlegner]

@sadhansood Sorry again for my original unqualified review. As already mentioned at #2020, we should ideally have a unified interface through which to perform run-time operations, either through a UNIX socket or through a separate port that is only available locally.

cc @liquid-helium