fix(usability): Improve the cache dir and database startup panics

[oxarbitrage]

Motivation

Currently, Zebra will panic any time it can’t create or open its state database. For example, if the cache directory is invalid, the disk is full, permissions are wrong, or the RocksDB instance is already in use. The default panic messages are ugly and make it hard for end users to diagnose the real cause.

Close #8617

Solution

We now split these failures into two categories:

• OS‑level errors (std::io::ErrorKind) related to the cache directory:

  • Permission denied
  • Disk full
  • Etc.

• RocksDB errors (rocksdb::ErrorKind) at the database-opening stage:

  • Database already in use
  • Other RocksDB‑specific failures

In DiskDB::new:

• Initialize the cache directory
  Attempt to create or open the cache directory first, and convert any std::io::ErrorKind into a descriptive panic.

• Open the RocksDB database
  Once the directory is validated, build the full DB path and open RocksDB, catching any rocksdb::ErrorKind and panicking.

This separation makes sure that each panic points more directly to its root cause and suggests an actionable hint.

Tests

• Updated the existing unit test to expect the new, more specific panic message.
• Manual verification test for both an OS‑level error (e.g., read‑only directory) and a RocksDB “already in use” error.

PR Checklist

• The PR name is suitable for the release notes.
• The solution is tested.
• The documentation is up to date.
• The PR has a priority label.
• If the PR shouldn't be in the release notes, it has the
  C-exclude-from-changelog label.

[gustavovalverde]

I did not fully validate the PR, but we should validate if the ZEBRA_CACHE_DIR is set, and create the directory where this variable indicates, or else to the default location.

[upbqdn]

I did not fully validate the PR, but we should validate if the ZEBRA_CACHE_DIR is set, and create the directory where this variable indicates, or else to the default location.

The ZEBRA_CACHE_DIR var takes effect only in tests, which this PR doesn't change. I think we could make a bunch of things easier if we dropped the var entirely.

[arya2]

I think we could make a bunch of things easier if we dropped the var entirely.

I think its purpose was to ensure that those tests are never run unintentionally, but I agree it would make a bunch of things easier to drop it and we may want to do that.

[arya2]

Thank you!

[upbqdn]

I think we could make a bunch of things easier if we dropped the var entirely.

I think its purpose was to ensure that those tests are never run unintentionally, but I agree it would make a bunch of things easier to drop it and we may want to do that.

This #9481 (comment) is a good motivation to drop the variables.

[upbqdn]

Also, the description in PR #9323.