create test cases for upgrading compatibility validation

[congxuebin]

To facilitate customer upgrades, it is planned to ensure binary swap compatibility within specific version ranges of cbdb. Therefore, the binary swap test is planned to be enabled.

The primary objective of creating the test cases is to validate that data created in an older version of the database remains accessible and usable after a binary format switch and upgrade. To achieve this, various types of tables and indexes were created, and data was loaded into each table with 10000 records. Data accessibility is then validated through queries and DML operations both before and after the upgrade.

Various types of tables:

Name	Type	Partition by	Storage
sales_ao	Table	None	Append-only
sales_aocs	Table	None	Append-only Columnar
sales_heap	Table	None	Heap
sales_partition_ao	Partitioned	Range	Append-only
sales_partition_aocs	Partitioned	Hash	Append-only Columnar
sales_partition_heap	Partitioned	List	Heap

Each table was populated with 10000 records, covering a variety of data types.

Index Types Used:

• B-tree
• Bitmap
• Unique
• BRIN (Block Range Index)

Data Validation:

• A series of queries were designed to access data with and without utilizing the created indexes.
• Bulk INSERT, UPDATE, and DELETE operations were added.

Test Script Modifications:

• The test script was updated to no longer rebuild the database after the binary format switch and upgrade.
  Instead, it verifies the continued functionality of existing data.

[avamingli]

It' hard to tell if we could support binary switch with different versions.
Our codes changes catalog across minor versions, we can't promise binary switch.
I'm declined not to add these cases until we are ready to promise.

[congxuebin]

Hi Mingli, @avamingli

Thanks for the comment. Right, we cannot guarantee binary compatibility across all versions. But as discussed with Max, this test is limited to ensuring compatibility within specific version ranges. For example, it ensures compatibility between 1.6.x and 1.6.0 to facilitate customer upgrades. However, we consider 1.6.x and 1.7 to be incompatible. Would it make sense?
I added more information about the background of this in PR description.

[avamingli]

For example, it ensures compatibility between 1.6.x and 1.6.0 to facilitate customer upgrades

Impossible, we changed catalog during Patch or revision versions. ex: gp_matview_aux, gp_matview_tables and etc.
This is different from GPDB, I think we will promise until there is a stable version.