op-service: create a common admin API RPC and a common RPC request metrics

[seungjulee]

Description

• 1. Separate out RPC server/client response/request metrics into op-service/metrics from op-node/metrics (perhaps this needs to be a separate PR. Please let me know if I need to do so) 56a6979
• 2. Extract the AdminAPI logic from op-node to op-service. d3c3a23 Use the consolidated AdminAPI for op-node and op-batcher 28aa528
• 3. Remove custom AdminAPI config from op-batcher, and move it to CLIFlags on op-service/server. 07647f5

This PR separates out AdminAPI functionality from op-node into op-service so that other packages like op-batcher that runs its own RPC server out of op-service/rpc can adopt the newly created AdminAPI without copying the logic.

This work is a part of op-service refactor effort. Specifically, this work was spun out from the below comment.

          Probably out of scope for this PR, but this would be nice to also have in op-service so the batcher/proposer/challenger would automatically inherit this capability.

Originally posted by @trianglesphere in #6895 (comment)

Tests
This is a simple refactor that does not change the existing logic. The change does not fail the existing tests.

I would love to get your opinion on where and how I should test the changes.

Additional context

cc @sebastianst @tynes @ajsutton perhaps this PR can be used as a supplementary way to evaluate my skills for the interview process.

Metadata

• Fixes op-service: standard admin RPC building block #7417

[trianglesphere]

If you could split it out into a PR for just the admin RPC & one just for the RPC metrics, that would make it easier toreview.

[seungjulee]

If you could split it out into a PR for just the admin RPC & one just for the RPC metrics, that would make it easier toreview.

I looked more on this, but this will create a two PRs that depends on another. Perhaps I'm misunderstanding, but the AdminAPI PR will inevitably touch on RPCMetrics PR, and will need to coordinate merging the two. If it's not too bothersome, I prefer to handle the two changes together in this PR.

But I can still split it out into two PRs. Let me know what I should do.

[trianglesphere]

If you could split it out into a PR for just the admin RPC & one just for the RPC metrics, that would make it easier toreview.

I looked more on this, but this will create a two PRs that depends on another. Perhaps I'm misunderstanding, but the AdminAPI PR will inevitably touch on RPCMetrics PR, and will need to coordinate merging the two. If it's not too bothersome, I prefer to handle the two changes together in this PR.

But I can still split it out into two PRs. Let me know what I should do.

This is fine to keep at one PR. Yes, there is a dependency with changes like this, but usually they can be stacked.

[trianglesphere]

TY for this fix

[trianglesphere]

@seungjulee could you merge in the latest from develop for CI?