Start ENSRainbow server immediately and download database in background

[djstrong]

For providing health checks in ENSRainbow we need to start ENSRainbow without database loaded. Based on #1605 (lazy loading of database during serving endpoints) we should run downloading and validation of database (entrypoint.sh) in background (using setTimeout, unsuccessful exit code should cause process.exit). This should be a new pnpm command, e.g. pnpm entrypoint.

ENSRainbow clients should wait for ready endpoint.

Revert changes from: #1607

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

• Create Plan

Examples

• Example 1
• Example 2

---

⚠️ Possible Duplicate Issue

• ENSApi & ENSIndexer re-try mechanism for long starting dependency (Render) #1303

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[lightwalker-eth]

@tk-o How would this idea influence the startup sequence of ENSIndexer? Do you see a solution where:

1. When ENSIndexer starts up, it prevents Ponder from starting until it gets a successful response from ENSRainbow's /ready endpoint.
2. ENSIndexer has logic for automatically retrying the /ready endpoint check.
3. Each time the /ready endpoint check might fail for any reason, helpful info is emitted into logs to help operators maintain good visibility for what's going on in their ENSNode deployment.

For planning this work, we should also review the highly related ideas in #1303

There's additional important questions we need to answer in planning this work, including:

1. How will ENSIndexer build its config (which relies on fetching from ENSRainbow). Will ENSRainbow return its config even before it is ready, or does it need to wait to become ready first? Will this issue cascade into ENSIndexer, such that ENSIndexer also cannot return its config until its own /ready endpoint says it is ready? And if so, how does this relate to how the /ready endpoint on ENSIndexer is actually implemented by Ponder's internals?
2. Let's imagine a 1-hour delay for ENSRainbow to become ready, which then also causes a 1-hour + 1-second delay for ENSIndexer to become ready. How will this influence ENSApi? I continue to have a strong preference to decouple ENSApi from ENSIndexer such that they only communicate through ENSDb. To solve all of this, would we want to update things so that when ENSIndexer starts up, even before it is able to build its own config because it may be waiting on ENSRainbow, that it writes something to ENSDb such that ENSIndexer can understand what's happening and gracefully wait for upstream services to become ready first?