Create health check and readiness check HTTP endpoints

[tk-o]

Ponder framework reserves /health and /ready HTTP endpoint and won't let ENSIndexer to have them overridden. Therefore, ENSIndexer will use custom endpoints, such as:

• /api/health
  • Specs to be added, will call /health endpoint + add custom logic
  • Possibly will check indexing status availablility (which confirms all dependencies have been loaded correctly)
• /api/ready
  • Specs to be added, will call /ready endpoint + add custom logic

[tk-o]

I've just had this idea: when implementing a client for an API, it'd be great if the client offered a way to its consumer to know when API becomes:

1. Healthy — which for ENSIndexer would happen when /api/health starts returning 200 OK.
2. Ready — which for ENSIndexer would happen when /api/ready starts returning 200 OK.

Example use case

ENSIndexer will have to use a worker to insert its public configuration and the current indexing status into ENSDb. The worker should not be started until ENSIndexer client is ready to respond. Otherwise, the worker would crash and would have to be restarted. It makes sense to only start the worker on the ENSIndexer client signalling readiness.

[lightwalker-eth]

@tk-o I like the spec in the overall description of this issue.

As for the proposed example use case, what you describe about the worker not starting until the ENSIndexer client is ready to respond is one option.

I assume a more architecturally simple option is to immediately start the worker that will write the metadata into ENSDb -- but this worker can simply have some logic to gracefully handle the case that the ENSIndexer client isn't able to generate the indexing status snapshot yet. That seems like a much better approach because it's so much simpler.