cuprated: Add graceful shutdown, pt2: service error propagation

[redsh4de]

What

Depends on pt1, PR #585

Building on part 1, this replaces the panic-on-error patterns in cuprated's services with error propagation that makes use of the graceful shutdown mechanism

Why

So we dont panic and insta-crash upon a error, shutdown should be graceful. Internal errors still caused panics before this via PANIC_CRITICAL_SERVICE_ERROR

Where

• cuprated:

  • blockchain/error.rs (new):

    Type	Kind	Variants
    BlockValidationError	peer-fault (ban)	HardFork(HardForkError), Other(ExtendedConsensusError)
    BlockManagerError	manager union	Validation(BlockValidationError), Internal(#[from] tower::BoxError)
    IncomingBlockError	interface union	Validation(BlockValidationError), Internal(tower::BoxError), Orphan, UnknownTransactions(_, _), TooManyTxs, ChannelClosed

  • txpool/error.rs (new):

    Type	Kind	Variants
    TxValidationError	peer-fault (ban)	Parse(io::Error), Consensus(ExtendedConsensusError), DuplicateTransaction, RelayRule(RelayRuleError)
    IncomingTxError	union	Validation(#[from] TxValidationError), Internal(#[from] tower::BoxError)

  • monitor.rs - add TaskExecutor::spawn_critical, panic_message helper.

  • logging.rs - return the log guard, hold it until shutdown completes.

  • constants.rs - rename PANIC_CRITICAL_SERVICE_ERROR to CRITICAL_SERVICE_ERROR

  • lib.rs - Node::launch returns Result; on init failure it cancels partially spawned subsystems before returning the error.

  • blockchain.rs - check_add_genesis returns Result.

  • blockchain/manager.rs - run loop returns Result, spawn_critical for syncer + manager.

  • blockchain/manager/handler.rs - .expect(...) -> ? throughout, handlers return Result<_, BlockManagerError> or Result<_, tower::BoxError>, handle_command routes Internal via ? and Validation via response channel. Invariant violations kept as panics.

  • txpool/manager.rs - uniform DB-error escalation: all 6 handlers propagate TxPoolError via ?. Reorder promote_tx and remove_tx_from_pool to write to DB first, then apply in memory.

  • txpool/incoming_tx.rs - IncomingTxHandler::init returns Result.

  • tor.rs, p2p.rs - transport_*_config / initialize_clearnet_p2p / initialize_tor_p2p return Result, Tor logs+skips on failure.

  • rpc/server.rs - init_rpc_servers returns Result, per-server task uses spawn - If a RPC server fails to start, the error is logged but doesn't initiate shutdown.

• cuprate-types
  • TxConversionError re-exported.

How

1. spawn_critical wraps each subsystem's future:

Outcome	Action
Ok(())	normal exit if shutdown was requested, else logged as a bug -> trigger shutdown
Err(_)	log w/ subsystem name -> trigger shutdown
panic	log via panic_message -> trigger shutdown

2. Added layered errors.

Per subsystem: a typed ValidationError for peer-fault paths, plus a union with Validation and Internal(tower::BoxError) arms. From impls route (ExtendedConsensusError::DBErr -> Internal; else -> Validation). The manager matches between the two:

Variant	Route	Caller's response
Internal(_)	? -> spawn_critical	log + graceful shutdown
Validation(_)	back via response channel	ban peer / cancel downloader

[redsh4de]

fwiw after these changes i kind of want to rename ExtendedConsensusError to ConsensusServiceError, as now its just used in service calls to differentiate whether a error is a consensus validation, or a service failure. easier to reason as well, but seperate pr

[Boog900]

Just a few nits