Database backend configuration

[RickiNano]

In the current implementation, the database backend is determined by the setting of RocksDb.Enable config setting which is not very intuitive.
This PR replaces that setting with a new database_backend setting. It can be set to either lmdb or rocksdb. If not set, it defaults to lmdb.
To make it easier for node operators that are currently using RocksDb, the node will notify the operator with an error message if the config file has the old RocksDb.Enable set to true and database_backend set to lmdb (for example when using an old config file that does not have the new database_backend property). The error message can be removed in future versions when operators have migrated to use the new database_backend type
This PR also makes it easier to add more backends in the future.

[gr0vity-dev-bot]

Test Results for Commit 6837b95

Pull Request 4828: Results
Overall Status: ✅

Test Case Results

• ✅ 5n4pr_conf_10k_bintree: PASS (Duration: 108s)
• ✅ 5n4pr_conf_10k_change: PASS (Duration: 131s)
• ✅ 5n4pr_conf_change_dependant: PASS (Duration: 126s)
• ✅ 5n4pr_conf_change_independant: PASS (Duration: 126s)
• ✅ 5n4pr_conf_send_dependant: PASS (Duration: 112s)
• ✅ 5n4pr_conf_send_independant: PASS (Duration: 117s)

Last updated: 2025-01-19 17:08:11 UTC

[pwojcikdev]

I agree with doing the backend configuration this way, but it should not throw an error if legacy rocksdb.enable is set. There should be a warning, but the node should check for this case and use rocksdb, there is no reason not to do that. It's not a good user experience otherwise.

The only case where we should throw an error is if there is a mismatch between rocksdb.enable and database_backend, ie. one is explicitly set to rocksdb and the other to lmdb.