catalog: internal table support about risinglight

[skyzh]

Internal tables should be using a separate executor. e.g., InternalTableExecutor, with different endpoints of our system (e.g., compactor, query engine, etc.) providing get_statistics(&self) -> DataChunk API to fetch the content of tables.

[skyzh]

... maybe our first internal table could be contributor list?

[xxchan]

I'm wondering how to maintain internal tables..

I'm considering a TableType for internal tables. For example, contributor list can be generated in scripts and passed by env!, so it is more like a memory table (or just use InMemoryTable directly). But the problem is that each storage engine is bound to its TableType, so I cannot use an InMemoryTable inside secondary engine. If we instead implement internal tables differently for each engine, it is not elegant and maybe is inproper (e.g., contributor list doesn't need to be stored on disk).

Another idea is to create a separate engine for internal tables, but it seems that we can only use one engine currently?