perf: Optimize table catalog cache

[crwen]

What problem does this PR solve?

Every time run a sql will create a KipTransaction and they all have their all table catalog cache. But table catalog cache may be not changed all the the time. So I move table catalog cache to KipStorage, and make KipTransaction share this cache.

Issue link: #162

What is changed and how it works?

Code changes

• Has Rust code change
• Has CI related scripts change

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Note for reviewer

[KKould]

This is a good idea. In issue: #162, it is a costly thing to get the table every time, but the reason why I have not done this is that I don’t After knowing this, will the table affect the correctness of the transaction? This may need to be considered when a transaction exists in DDL, DQL, or DML, and table_cache can only be actually modified when it is submitted.

I know that SQLite may have such a function, but in my impression SQLite only supports a single write transaction at the same time, while FnckSQL can allow multiple write transactions at the same time.

I don't think what pr can currently see is able to get the results right, it can be a very complicated thing

Tips: I deliberately set the table_cache size in KipTransaction to be smaller because I think that only a few tables are often involved in a single transaction.

[KKould]

I found that DDL should only have one transaction at the same time, are you interested in implementing this? because it can implement table_cache, the issue is here: #171,

[KKould]

I found a similar concept: mysql mdl(metadata lock), we can refer to this to implement it in the Database layer instead of the Server layer

[KKould]

merged on #177