Clean up redundant code for TiFlash

[JaySon-Huang]

TiFlash fork from Clickhouse around late 2018. There are lots of useless codes for TiFlash.

• Remove StorageKafka, StorageMySQL, StorageODBC and CapnProtoRowInputStream Remove useless codes #1279
• (Mainly) Remove documents for Clickhouse Remove useless files for TiFlash #1596
• Remove ReplicatedMergeTree family (TiFlash does not rely on those storage engines to do replication) Remove ReplicatedMergeTree family #1805
• Remove MergeTree family #3481
• Remove StorageDistributed #3484
• Automatically update related generated-cpp files after kvproto/tipb get updated Better integration with tipb, kvproto #2110
• Remove some useless dependency for TiFlash.
  • kafka Reduction of extraneous compoents  #2022
  • MongoDB, MySQL, odbc Reduction of extraneous compoents  #2022
  • XML
    Clickhouse uses XML as the configuration file format but TiFlash uses toml. Seems that TiFlash do not rely on XML anymore.
  • Zookeeper Remove ClickHouse DDL worker #2253 Remove ZooKeeper #2255
    Clickhouse use zookeeper for replication, but TiFlash rely on PD and TiKV's Raft layer
• Remove Analyzers Remove useless Analyzers #2497 Remove uesless Analyzers #2549
• Remove ClickHouse integration test cases under dbms/tests #3485
• Remove Interpreters/{Users,SecurityManager,Quota} and related logics #3486
  These are outdated permission management, resource management from ClickHouse
• Remove unused configuration "interserver_http_port" #3491

Something not sure:

• Remove redundant data types so that we don't need to instantiate some template class for these data types, which may greatly reduce our compile time
  • "DataTypeDate"/"DateTypeDateTime"
    We use "DataTypeMyDate"/"DataTypeMyDatetime" for MySQL/TiDB-compatibility, these original data types ported from Clickhouse are useless for TiFlash
  • "DataTypeTuple"/"DataTypeArray"/"DataTypeSet"
    We don't use these data type

Possible it is good for speeding up our CI building step #1390.

[JaySon-Huang]

/cc @birdstorm @solotzg

[SchrodingerZhu]

I think during the cleanup, one can also try to eliminate warnings.
Personally, I think it is a good idea to keep -Wall -Wextra -Werror; warnings are helpful for find silly bugs and typos at the first place.
For some special situations, like memcpy on non-trivial structs, if we are confident about the safety, we can wrap up them with pragmas to make the compiler happy.
Huge work is needed but I think it is worthy of the efforts to have a clean code base.

[JaySon-Huang]

I think during the cleanup, one can also try to eliminate warnings.
Personally, I think it is a good idea to keep -Wall -Wextra -Werror; warnings are helpful for find silly bugs and typos at the first place.
For some special situations, like memcpy on non-trivial structs, if we are confident about the safety, we can wrap up them with pragmas to make the compiler happy.
Huge work is needed but I think it is worthy of the efforts to have a clean code base.

A related issue under Apple clang 12.0.5 #1887

[solotzg]

#2020 this pr could optimize time cost of tics_ghpr_build from 45mins to 14mins if nearly 80% cache hit. @JaySon-Huang

[JaySon-Huang]

#2020 this pr could optimize time cost of tics_ghpr_build from 45mins to 14mins if nearly 80% cache hit. @JaySon-Huang

Great to see that our building CI down to 14 mins!

I open this issue mainly for cleaning up redundant codes so that we can have a more clean codebase. This may be good for those new to the TiFlash project and help us if TiFlash gets opened to the public someday.
Speeding up our building CI may be a side effect of it.

[ywqzzy]

Is storageFile related code useless?

[JaySon-Huang]

@ywqzzy StorageFile is used by TableFunctionFile, I think both of them are useless for TiFlash.

[ywqzzy]

@ywqzzy StorageFile is used by TableFunctionFile, I think both of them are useless for TiFlash.

I will remove all of them.