WIP: health/ endpoint

[suchapalaver]

WIP: CHRON-450

• Wraps our Prometheus metrics listener as another poem Route::at alongside other --offer-endpoints (currently data and graphql) so it listens alongside them on a /metrics path off API_LISTEN_SOCKET - takes care of CHRON-450
• Adds health/ endpoint that check current metrics from depth charge and returns 500
• Improve response by including JSON with current round trip time
• Review the need to parse String from rendered metrics
• Figure out defaults - coupling of health endpoint with health metrics and the latter's configuration
• Update Helm Chart

PR Checklist

Please complete this checklist after opening your PR

• I have updated documentation as necessary
• I have updated helm chart(s) if needed
• I have added tests if needed
• All new and existing tests are passing
• Any breaking changes are clearly flagged and documented
• I’ve included a link to any relevant ticket(s)

[mtbc]

Perhaps a set of enum values?

[mtbc]

(That's just me thinking aloud, it's fine if you prefer it as it is, feel free to resolve this.)

[ryan-s-roberts]

They are not all mutually exclusive or related, but I agree seeing more than 2 bools at once is a worry. We may be pushing complexity up to configuration here. Simple data / graphql are always reasonable to assume. As they have known base urls, infrastructure can be used to exclude.

It's only health / metrics thats a choice here. Our current requirement is health, we can deal with exposing a prometheus endpoint properly later.

This is my fault, as I thought a prometheus endpoint would be basically free if we based health on metrics - apparently not the case but we will be able to figure it out.

[mtbc]

Though, I'm happy for none of this to be figured out in this PR if we'd prefer a separate ticket for endpoint conf (or not), at least it's just simple on-off configuration for separable things.

[suchapalaver]

This was simply because the compiler was complaining about too many args in a function so I put them in a struct together.

[ryan-s-roberts]

They are not all mutually exclusive or related, but I agree seeing more than 2 bools at once is a worry. We may be pushing complexity up to configuration here. Simple data / graphql are always reasonable to assume. As they have known base urls, infrastructure can be used to exclude.

It's only health / metrics thats a choice here. Our current requirement is health, we can deal with exposing a prometheus endpoint properly later.

This is my fault, as I thought a prometheus endpoint would be basically free if we based health on metrics - apparently not the case but we will be able to figure it out.