Add external database storage adapter to support high-volume WalletConnect clients

[paranormal]

Following this question: Serving hundreds of thousands.

Our company has implemented a solution to address this scalability problem, and we’d like to contribute it back to the main codebase.

Summary of proposed changes

1. Controller logic refactor:
   • Controllers now process and store items individually, instead of batching them in memory.
   • They no longer keep large in-memory caches; instead, they fetch items directly from the store whenever needed.
   • This removes reliance on persist calls to sync a local cache with the store and reduces heap usage.
2. Introducing a new Store interface compatible with PostgreSQL/MongoDB

import { ErrorResponse } from "@walletconnect/jsonrpc-types";
import { Logger } from "@walletconnect/logger";
import { ICore } from "./core";

export type Query<Value> = Partial<{
  [K in keyof Value]:
    | Partial<Value[K]>
    | { ["$lt"]: Value[K] }
    | { ["$lte"]: Value[K] }
    | { ["$gt"]: Value[K] }
    | { ["$gte"]: Value[K] }
    | { ["$ne"]: Value[K] | null }
    | { ["$eq"]: Value[K] | null }
    | { ["$nin"]: Value[K][] }
    | { ["$in"]: Value[K][] };
}>;

export abstract class IStore<Key, Value, Filter = Query<Value>> {
  public abstract readonly context: string;

  constructor(public core: ICore, public logger: Logger, public name: string) {}

  public abstract init(): Promise<void>;

  public abstract keys(filter?: Filter): Promise<Key[]>;

  public abstract length(key?: Key, filter?: Filter): Promise<number>;

  public abstract set(key: Key, value: Value): Promise<void>;

  public abstract get(key: Key): Promise<Value>;

  public abstract has(key: Key): Promise<boolean>;

  public abstract getAll(filter?: Filter): Promise<Value[]>;

  public abstract update(key: Key, update: Partial<Value>): Promise<void>;

  public abstract delete(key: Key, reason: ErrorResponse): Promise<void>;

  public abstract deleteAll(keys: Key[], reason: ErrorResponse): Promise<void>;
}

Exposing an additional Store interface would be straightforward to integrate into the current codebase.
The main discussion point is the change in controller logic: currently, items live in memory (heap) and are periodically synced to the database; our approach moves to a database-first model, where all state is persisted immediately, and controllers operate directly from the store.

Note: This involves a substantial number of changes.