Refactor Warp Filter Initialization For Metrics Reset

[nlordell]

This PR refactors how we initialize our warp router and ensures that metrics are initialized for all requests.

This is a QOL change to improve Grafana metrics around API request responses. This is because, if we don't reset metrics to 0 they don't exist at all until the first time we increment their counter. This causes no-data alerts in Grafana alerts and can make panels weird to look at.

Test Plan

Run some sample queries and see they still work:

% curl -s http://localhost:8080/api/v1/quote -X POST -H 'content-type: application/json' --data '@-' <<JSON | jq
{
  "from": "0x0000000000000000000000000000000000000000",
  "sellToken": "0xdac17f958d2ee523a2206206994597c13d831ec7",
  "buyToken": "0x6b175474e89094c44da98b954eedeac495271d0f",
  "kind": "sell",
  "sellAmountBeforeFee": "1000000000"
}
JSON
{
  "quote": {
    "sellToken": "0xdac17f958d2ee523a2206206994597c13d831ec7",
    "buyToken": "0x6b175474e89094c44da98b954eedeac495271d0f",
    "receiver": null,
    "sellAmount": "996326028",
    "buyAmount": "992459269806446405282",
    "validTo": 1668605853,
    "appData": "0x0000000000000000000000000000000000000000000000000000000000000000",
    "feeAmount": "3673972",
    "kind": "sell",
    "partiallyFillable": false,
    "sellTokenBalance": "erc20",
    "buyTokenBalance": "erc20",
    "signingScheme": "eip712"
  },
  "from": "0x0000000000000000000000000000000000000000",
  "expiration": "2022-11-16T13:08:33.276651Z",
  "id": 4
}

Also, fetch metrics and see we initialized a bunch of request metrics:

% curl -s http://localhost:9586/metrics
...
gp_v2_api_api_requests_complete{method="v1/version",status_code="200"} 0
gp_v2_api_api_requests_complete{method="v1/version",status_code="201"} 0
gp_v2_api_api_requests_complete{method="v1/version",status_code="400"} 0
gp_v2_api_api_requests_complete{method="v1/version",status_code="401"} 0
gp_v2_api_api_requests_complete{method="v1/version",status_code="403"} 0
gp_v2_api_api_requests_complete{method="v1/version",status_code="404"} 0
gp_v2_api_api_requests_complete{method="v1/version",status_code="500"} 0
gp_v2_api_api_requests_complete{method="v1/version",status_code="503"} 0
...

[vkgnosis]

For context, the problem is that if we don't reset metrics to 0 they don't exist at all until the first time we increment their counter. This causes no-data alerts in Grafana alerts and can make panels weird to look at.

[nlordell]

For context, the problem is that if we don't reset metrics to 0 they don't exist at all until the first time we increment their counter. This causes no-data alerts in Grafana alerts and can make panels weird to look at.

Added this to the PR description.

[sistemd]

I'm not thrilled with the proliferation of v1 prefixes, but if there's no other way it's not that big of a deal anyway.

[nlordell]

I'm not thrilled with the proliferation of v1 prefixes

Interesting, I actually thought it was "more correct". For example, the get_solvable_orders_v2 module clearly expects to be a v2 route, but required the caller to install it in the right place (instead of having the caller just chose the prefix (api in this case). WDYT?

Otherwise, we can easily change the router definition to insert v1 and v2 when creating the routes.