Built Ponder Client and rename ponder-metadata to ponder-sdk

[lightwalker-eth]

This logic now exclusively lives inside ENSIndexer. We shouldn't make an effort for this logic to be usable more broadly outside of ENSIndexer.

[tk-o]

@lightwalker-eth I think we can keep the ponder-metadata package but turn it private and stop publishing it.

There are couple of reasons for keeping the package:

1. Isolate dependencies for working with, for example, Prometheus metrics.
2. Keep consistent codebase patterns

• Just like we have ponder-subgraph package for managing Subgraph API integration with Ponder. We could also have a separate package for defining Ponder-related ideas in one place.
  • Involves moving https://github.com/namehash/ensnode/tree/v0.35.0/apps/ensindexer/src/api/lib/indexing-status/ponder-metadata into https://github.com/namehash/ensnode/tree/v0.35.0/packages/ponder-metadata

[lightwalker-eth]

Suggest we keep this package but rename it to ponder-sdk.

Then, inside of this package we should define a "Ponder Client" that would be an API client a bit like the API client we built for ENSRainbow. A key difference though is that we should make the "Ponder Client" not as lightweight. We need the "Ponder Client" to implement distinct functions that wrap each of Ponder's APIs that we care about. Ex: If we care about 2 of Ponder's APIs, we need to implement 2 distinct functions, where each is a wrapper around exactly 1 Ponder API call.

The data model of Ponder's API response schemas is not ideal for us to work with. Therefore each API handler in this "Ponder Client" needs to take the responsibility of parsing / deserializing the Ponder API responses and returning back a really nice data model for our business logic to work with. Absolutely nothing messy about Ponder's API responses should "leak out" of the "Ponder Client" implementation. For example, how Ponder uses chain names or uses Prometheus should be completely contained within "Ponder Client" and should NOT leak out in any way.

We should NOT design the "really nice data model" that the "Ponder Client" returns to be a universal solution for everyone. It should ONLY contain the fields that we care about and absolutely nothing more.

All our logic that current makes Ponder API calls needs to be refactored to use this "Ponder Client" instead.

Ponder Client should support all Ponder reserved routes:
GET /health returns 200 immediately when ponder starts running
GET /ready returns 200 when ponder completed historical indexing
GET /status returns status object (that we later replay with /GET metadata)
GET /mertics returns prometheus metrics (we use some with GET /metadata)