feat(iota-core,iota-node): cleanup indexes config values

[muXxer]

Description of change

Makes a node that serves an API serve every endpoint of that API, and honours the configured index retention verbatim.

Two inconsistencies were left behind by the unified rpc_indexes store:

enable-index-processing decided too little. It controlled whether the JSON-RPC index tables were maintained, but the JSON-RPC server started unconditionally on every fullnode. A node could advertise iotax_getOwnedObjects, iotax_getCoins, iotax_queryTransactionBlocks and the rest while they all answered IndexStoreNotAvailable, so a client that could open a connection still had to probe method by method to learn what the node would actually answer.

It is replaced by enable-jsonrpc-api (default true), which gates the API and its index together — the same shape enable-grpc-api already has. With it off, build_http_server returns Ok(None) and nothing is mounted on json-rpc-address, the /health endpoint included, mirroring gRPC's health check, which is a method on the ledger service and disappears with the gRPC API. Metrics and the admin interface start independently of both flags, so a node serving neither API stays observable.

num-epochs-to-retain-for-indexes was not honoured. A MIN_EPOCHS_TO_RETAIN_FOR_INDEXES = 7 floor silently raised any smaller value to 7. The floor is gone; the configured value is now used as written. Retention counts the current epoch, so 1 keeps the current epoch only and 2 the current plus the previous. Unset still means retain everything and remains the default — no default changed.

0 is rejected at startup rather than clamped: the running epoch's history is written whatever the retention says, because checkpoint ingest reads that epoch's transaction digests to tell an already-indexed transaction from a new one. Since every other value is now honoured exactly, silently reinterpreting one of them would reintroduce the surprise this change removes. Separately, and not the same thing, RpcIndexesStore::prune guards the newest bucket at its own API boundary, because tests and tools reach prune without passing through config validation.

Upgrade behaviour. NodeConfig has no deny_unknown_fields, so a config still carrying enable-index-processing would have had that key silently dropped and fallen back to enable-jsonrpc-api: true — quietly giving a node explicitly configured not to serve JSON-RPC both a public listener on the 0.0.0.0:9000 default and a blocking full index rebuild at startup. The old key is therefore retained solely as a tripwire: a node whose config still names it refuses to start, with a message pointing at the replacement.

Stacked on #12645.

Links to any relevant issues

How the change has been tested

• Basic tests (linting, compilation, formatting, unit/integration tests)
• Patch-specific tests (correctness, functionality coverage)
• I have added tests that prove my fix is effective or that my feature works
• I have checked that new and existing unit tests pass locally with my changes

cargo clippy -p iota-config -p iota-node -p iota-core -p iota-swarm-config -p iota-swarm -p test-cluster -p iota-e2e-tests --all-targets --all-features -- -D warnings clean; IOTA_SKIP_SIMTESTS=1 cargo nextest run -p iota-core --lib -p iota-config -p iota-swarm-config 854/854; cargo simtest -p iota-e2e-tests 291/291; cargo check --workspace --all-targets clean.

New tests: every index-backed JSON-RPC method answers on a node serving the API; a node with the API off mounts nothing on its JSON-RPC address (driven through Swarm, since a TestCluster cannot be built against a node with no JSON-RPC client); retention of 1 and 2 retain exactly the expected epochs; pruning keeps the newest bucket whatever the retention, and that bucket stays writable for ingest; a config carrying the retired key fails startup.

Release Notes

• Protocol:
• Nodes (Validators and Full nodes): enable-index-processing is replaced by enable-jsonrpc-api (default true), which gates the JSON-RPC API itself as well as its index, so a node either serves every JSON-RPC method or mounts nothing on its JSON-RPC address — including the /health endpoint, which now follows the API the way the gRPC health check follows the gRPC API, with the metrics and admin interfaces unaffected; a node whose config still carries enable-index-processing refuses to start rather than silently changing behaviour; num-epochs-to-retain-for-indexes is now honoured verbatim with no seven-epoch floor and counts the current epoch, so 1 keeps the current epoch only and 0 is rejected at startup.
• Indexer:
• JSON-RPC: A node that serves the JSON-RPC API serves all of its index-backed methods, so iotax_getOwnedObjects, iotax_getCoins, the balance and dynamic-field reads, iotax_queryTransactionBlocks and iotax_queryEvents no longer answer IndexStoreNotAvailable on a node that otherwise looks healthy.
• GraphQL:
• CLI:
• Rust SDK:
• gRPC:

Breaking Changes Rollout

Affected Crates:

• iota-config
• iota-node
• iota-core

Required User Actions:

• devnet: Operators must rename enable-index-processing to enable-jsonrpc-api in their node config; a node whose config still carries the old key refuses to start with a message naming the new one, rather than silently falling back to the enable-jsonrpc-api default of true. Operators probing /health on a node that turns the JSON-RPC API off must move that probe to the gRPC health check or the metrics endpoint, since nothing is mounted on the JSON-RPC address any more. Operators who set num-epochs-to-retain-for-indexes below 7 previously got 7 and now get the value they asked for, so index history shrinks accordingly; a value of 0 now fails startup and must become 1 or the API must be turned off.
• testnet: Same actions as devnet.
• mainnet: Same actions as devnet.