Fix flakyness in isolation_reference_table (#6193)

The newly introduced isolation_reference_table test had some flakyness,
because the assumption on how the arbitrary reference table gets chosen
was incorrect. This introduces a VACUUM FULL at the start of the test to
ensure the assumption actually holds.

Example of failed test: https://app.circleci.com/pipelines/github/citusdata/citus/26108/workflows/0a5cd526-006b-423e-8b67-7411b9c6be36/jobs/736802

src/test/regress/spec/isolation_reference_table.spec

@@ -1,6 +1,17 @@
-// reference tables _do_ lock on the first reference table in the shardgroup due to the lack of shardgroups in the
+// reference tables _do_ lock on the first reference table in the shardgroup
-// system. When we run the tests we want to make sure the tables we are testing against cannot be the first reference
+// due to the lack of shardgroups in the system. When we run the tests we want
-// table. For this purpose we create a reference table that we will _not_ interact with during the tests.
+// to make sure the tables we are testing against cannot be the first reference
+// table. For this purpose we create a reference table that we will _not_
+// interact with during the tests. However, when a VACUUM happens on
+// pg_dist_partition in the middle of the test, to table that we don't use on
+// purpose might not actually be the first in the catalogs. To avoid VACUUM
+// running we run VACUUM FULL on pg_dist_partition before we run this test.
+// This VACUUM is done in a separate setup block because it cannot run in a
+// transaction.
+setup
+{
+	VACUUM FULL pg_dist_partition;
+}
 setup
 {
  	CREATE TABLE first_reference_table(a int);