Modularize beacon node backend

[eserilev]

Description

I am creating this issue to track the progress of my work surrounding the enabling of multiple database implementations for the beacon node. The initial goal is to modularize the beacon node backend and abstract over the current LevelDB implementation. We'll eventually want to add a second database implementation. Theres some work being done on #4424 to add several new database implementations to the slasher backend. We may be able to decide on a relevant database implementation to add to the beacon node based on the current work being done on the slasher.

I plan to use the modularized slasher backend as a "blueprint" for my work on the beacon node. Similar to the slasher, I'll add a interface.rs file that allow us to abstract over different database implementations. That interface should encapsulate all the relevant database operations needed for the beacon node. Tentatively it will look something like this:

impl Environment {
    pub fn new(config: &StoreConfig) {
    }

    pub fn create_database(&self) {
    }

    pub fn create_rw_transaction(&self) {
    }
}

impl RwTransaction {
    pub fn put_with_options(&self) {
    }

    pub fn get(&self) {
    }

    pub fn delete(&self) { 
    }

    pub fn do_atomically(&self, ops_batch: Vec<KeyValueStoreOp>) {
    }

    pub fn compact(&self) {
    }

    pub fn iter_column(&self) {
    }
}

[michaelsproul]

Sounds great @eserilev! There is an existing trait called KeyValueStore which does part of the abstract-ing already. The problem is that large parts of Lighthouse assume that the KV store is always LevelDB (in type aliases, etc)

[jimmygchen]

Completed in #4718 🎉 woot