Combine `VolatileCatalog` and `Cluster`

[waynexia]

Describe This Problem

Reference to #235:

Cluster is responsible to manage Tables and Shards while Catalog is responsible to manage Schemas which is a group of tables in another perspective different from Shard. Their functionalities have a big part that overlaps. It's natural to implement both Cluster and Catalog traits over one struct, so they can use one memory state and maybe one operation logic.

Proposal

• [ ] Make a triple to act as TableRef's full identifier(token)

  struct TableToken {
      catalog: CatalogId,
      schema: SchemaId,
      table: TableId,
  }
  

  We currently use the three layers separately: first get a Catalog instance, and get Schema instance from it, then get Table instance. And the storage needs a nested map struct to put all this infos. The entire procedure can be simplified.

• [ ] Remove CatalogManager and SchemaManager to reduce the complexity and simplify interfaces. Now only keep a top-level Manager and low-level TableManager

  Follows the above description. CatalogManager and SchemaManager's interfaces are redundant in some sorts.

• [x] Manage all the TableRef in one place, here is TableManager insides Cluster #260

  The one who keeps all TableRef should be able to serve two requests:

  • get tables by shard
  • get tables by catalog/schema/table

  the fields in TableManager may look like

  struct TableManager {
      // ...
      tables: BTreeMap<TableToken, TableRef>,
      shards: HashMap<ShardId, HashSet<TableToken>>,
  }
  

Additional Context

• [ ] (optional) Unify the name and id. Like SchemaName and SchemaId

  enum CatalogToken{
      Id(CatalogId),
      Name(String)
  }