fix(go-client): Changed the validation logic for new configuration during queryconfig operation

[nanorth]

What problem does this PR solve?

In the current code, after querying the configuration, there is a check on the new partition count, which must be either equal to, double, or half of the previous count.

incubator-pegasus/go-client/pegasus/table_connector.go

Lines 286 to 288 in e42f1a6

	func isPartitionValid(oldCount int, respCount int) bool {
	return oldCount == 0 || oldCount == respCount || oldCount*2 == respCount || oldCount == respCount*2
	}

However, in certain scenarios, when dealing with partitions that consume excessive disk space, we may manually split a single partition into multiple partitions, potentially increasing the partition count by a factor of 8 or more. This is typically done by performing multiple split operations offline and reconstructing the data on another cluster, with metaproxy used to ensure seamless traffic switching. When we modify the meta address in the table's metaproxy, an update config is triggered and the partition count is found to have increased multiple times.

Therefore, when updating the configuration, we do not require the new partition count to be related to the previous one. The previous validation logic becomes too restrictive and incorrect.

What is changed and how does it

This PR removes the check that requires the new partition count to be equal to, double, or half of the old one. Instead, it only checks whether the new partition count is valid (greater than or equal to 4 and is a power of 2).

Tests

• Unit test included

[acelyc111]

How about checking respCount/oldCount is power of 2?

[nanorth]

In the case of traffic switching, there is no direct relationship between the partition counts of the old and new tables. I think as long as respCount is valid (a power of 2 and >= 4), it should be fine. We don't really care about oldCount in this scenario.