support non-integer request ids

[pirtleshell]

EVM requests can have strings as their id, not just integers.

A brief glimpse at the logs on prod shows that requests with ids that are string uuids or string numbers are failing to decode which causes them to skip the cache and never create metrics.

This PR changes the ID field of EVMRPCRequestEnvelope from int64 to interface{} in order to support string ids (and even booleans, which return valid responses when queried over the EVM). E2E test confirming requests with string ids can now be fielded by the cache is included 👍

Other improvements:

• change a noisy caching middleware log to Trace (anytime a request can't be cached due to it not containing a block number, it logs an error)
• update tests that inspect metrics to be more resilient. faster machines look for the metrics before they are actually created. a 10ms buffer is added to all tests that query for metrics over a time window.
• update main_test to use require not assert so there is clear indication which assertion a failure is coming from

[pirtleshell]

every occurrence of this helper func used time.Now() as the endTime so i made that an assumption of the func.
this allows us to secretly sleep for 10 microseconds in order to allow metrics to actually be created.

doing so fixes frequent but random test failures that look like expected 4 metrics but found 2 or [] does not contain yada yada

[evgeniy-scherbina]

LGTM

fyi: recently we added additional CI job, which triggers front-end e2e tests: https://github.com/Kava-Labs/kava-proxy-service/actions/runs/6907131300/job/18800458169

the only issue to make sure it works properly, I'd recommend such steps:

• merge to master
• wait until kava-proxy-service will be deployed to internal-testnet
• retrigger this job: https://github.com/Kava-Labs/kava-proxy-service/blob/main/.github/workflows/ci-webapp-e2e-tests.yml

without waiting and re-triggering it may be the case, that job is successful, but was run against old internal-testnet (front-end e2e tests are run against internal-testnet)

front-end e2e tests helped me to find few very weird bugs (which was impossible to find during unit/e2e tests, for ex. related to CORS, etc...)

also I agree regarding logs, logs are very noisy, definitely need to improve it