Make the writing API of read-only databases inaccessible

[upbqdn]

Motivation

PR #8079 adds support for opening the database in a read-only mode. However, the writing functionality still remains accessible in the API of the returned database. We should make it inaccessible for read-only databases. Note that this is not a security issue since attempting to write to a read-only database fails or panics, and the writes are not remotely triggerable.

Possible Solutions

One possible solution is having a type that implements all the read methods, but only implements the two write methods: write(batch) and spawn_format_change() when it is a read-write database. This can be implemented using a generic parameter that allows writing.

One possible implementation is adding an IsWriteable generic to the database and TypedColumnFamily, and only implementing TypedColumnFamily::for_writing() when the generic is ReadWriteDatabase.

After PR #8112, this should be implemented on TypedColumnFamily and WriteTypedBatch.

For example, the second generic parameter here is required to be DBWithThreadModeInner, we could do something similar with a ReadWriteDatabase unit struct:
https://docs.rs/rocksdb/latest/rocksdb/struct.DBCommon.html#impl-DBCommon%3CT,+DBWithThreadModeInner%3E

And here are the methods that work regardless of the generic type (for us that would be read methods):
https://docs.rs/rocksdb/latest/rocksdb/struct.DBCommon.html#impl-DBCommon%3CT,+D%3E

Credit to Teor for outlining the solutions.

Documentation

Document that secondary/read-only instances only read data that is in the database when it is opened. A specific method needs to be called to make secondary instances get more data:
https://github.com/facebook/rocksdb/wiki/Read-only-and-Secondary-instances

Document that the supported way to get read-only access to the state from a separate process is RPCs, and within the same process is cloning a ReadStateService. This is because we have a non-finalized state containing blocks not in the database.

[mpguerra]

would this be a potential security issue for the blockchain scanner? If so we can add it to the list of tasks to do at some point after the MVP...

[upbqdn]

I don't think so because writing would fail or panic. I added this note to the description:

Note that this is not a security issue since attempting to write to a read-only database fails or panics, and the writes are not remotely triggerable.

[teor2345]

It might also be helpful to document that the supported way to get read-only access to the state from a separate process is RPCs, and within the same process is cloning a ReadStateService. This is because we have a non-finalized state containing blocks not in the database.

I'll add this to the ticket.

[teor2345]

We might want to think about how to do this with TypedColumnFamily and WriteTypedBatch after PR #8112.

One possible implementation is adding an IsWriteable generic to the database and TypedColumnFamily, and only implementing TypedColumnFamily::for_writing() when the generic is ReadWriteDatabase.

[mpguerra]

Is this work relevant outside of the scanner work?

[upbqdn]

If Zaino is going to use this API, then I think we should do it as part of work on Zaino. And if Zaino is going to build and use some other API, then we should delete this API entirely, and keep only the other one.