storcon: Introduce deletion tombstones to support flaky node scenario

[ephemeralsad]

Problem

Removed nodes can re-add themselves on restart if not properly tombstoned. We need a mechanism (e.g. soft-delete flag) to prevent this, especially in cases where the node is unreachable.

More details there: #12036

Summary of changes

• Introduced NodeLifecycle enum to represent node lifecycle states.
• Added a string representation of NodeLifecycle to the nodes table.
• Implemented node removal using a tombstone mechanism.
• Introduced /debug/v1/tombstone* handlers to manage the tombstone state.

[github-actions]

8459 tests run: 7877 passed, 0 failed, 582 skipped (full report)

---

Flaky tests (1)

Postgres 14

• test_sharding_split_failures[failure10]: release-arm64-with-lfc

Code coverage* (full report)

• functions: 32.2% (9018 of 27988 functions)
• lines: 48.5% (80021 of 165092 lines)

* collected from Rust tests only

---

_{The comment gets automatically updated with the latest test results
cee59e7 at 2025-06-06T06:00:23.378Z :recycle:}

[VladLazar]

Generally looks good. Got some points around robustness. Let me know if you wanna walk through anything on a call.

---

Let's add a test that covers our main scenario: preventing a flaky node from re-attaching by marking it soft deleted. Bonus points for covering concurrency between re-attach and node deletion. test_storage_controller.py is a good starting point.

---

Please update the cover letter with a description of the problem we are solving here.
It's better to have actual descriptions in the commit history than GH links.

[github-actions]

If this PR added a GUC in the Postgres fork or neon extension,
please regenerate the Postgres settings in the cloud repo:

make NEON_WORKDIR=path/to/neon/checkout \
  -C goapp/internal/shareddomain/postgres generate

If you're an external contributor, a Neon employee will assist in
making sure this step is done.

[VladLazar]

LGTM - give it a go in staging and update the docs for PS decom if required.

---

Small piece of feedback: we usually resolve review comments with a link to the commit that fixed it. This makes it easier for the reviewer to know if the change was applied and where.