feat(issue-253): initial metrics implementation

[0xste]

📝 Summary

An initial prometheus http server exposed optionally on a custom port if flag is provided at runtime.

⛱ Motivation and Context

As per discussion on: #294 (comment) i've reduced the scope of the change to be as minimal as possible and look to incrementally add additional metrics over time to de-risk the implementation

Following the step 1 recommendation on: #253 (comment)

📚 References

#253

---

✅ I have run these commands

• make lint
• make test-race
• go mod tidy

[n0price]

Are you planning expose MEV Boost metrics?

[0xste]

Are you planning expose MEV Boost metrics?

Yes! i'd proposed a full integration that was rejected here a while back #294 on the grounds of the changes being too deep into the codebase

These changes are deep and extensive into the core system and logic. Considering that mev-boost is run at 50% of all validators, it is too risky and impactful for adding a large amount of new logic in the core flows at the current time.
Perhaps consider collecting the metrics from the logs, or thinking about a possible plugin interface. 🤔

• Add prometheus metrics endpoint #294 (comment)

This MR is step 1 of the recommendation instrumentation is introduced gradually to reduce operator risk

I propose we implement this change in stages to de-risk the implementation

1. Implement the standalone server on the new port and expose only default metrics about the go runtime
2. Implement metrics for HTTP Server interaction
3. Implement basic metrics for internal MEV details
4. More advanced MEV statistics

• Prometheus metrics #253 (comment)