pub fn configure_storage_values_cache(
        &mut self,
        capacity: u64,
        max_l2_blocks_lag: u32,
        connection_pool: ConnectionPool<Core>,
    ) -> PostgresStorageCachesTask {
        assert!(
            capacity > 0,
            "Storage values cache capacity must be positive"
        );
        tracing::debug!("Initializing VM storage values cache with {capacity}B capacity");

        let (command_sender, command_receiver) = watch::channel((L2BlockNumber(0), Instant::now()));
        let values_cache = ValuesCache::new(capacity);
        self.values = Some(ValuesCacheAndUpdater {
            cache: values_cache.clone(),
            command_sender: Arc::new(command_sender),
        });

        // We want to run updates in a separate task in order to not block VM execution on update
        // and keep contention over the `ValuesCache` lock as low as possible. As a downside,
        // `Self::schedule_values_update()` will produce some no-op update commands from concurrently
        // executing VM instances. Due to built-in filtering, this seems manageable.
        PostgresStorageCachesTask {
            connection_pool,
            values_cache,
            max_l2_blocks_lag,
            command_receiver,
        }
    }
Configures the VM storage values cache. The returned closure is the background task that will update
the cache according to [`Self::schedule_values_update()`] calls. It should be spawned on a separate thread
or a blocking Tokio task.

# Panics

Panics if provided `capacity` is zero. (Check on the caller side beforehand if there is
such possibility.)
core/lib/state/src/postgres/mod.rs