Remove workaround for Oid collision in pg_upgrade testing

Commit 98627fe7 introduced a workaround
for Oid collisions stemming partition exchange of heap relations
that lack an array type. Commit 73434db2
introduced a preallocation check to the Oid dispatcher which now
is responsible for avoiding these collisions. Remove the workaround
from the pre-test script.
Reviewed-by: NJacob Champion <pchampion@pivotal.io>
Reviewed-by: NShaoqi Bai <sbai@pivotal.io>

contrib/pg_upgrade/test_gpdb_pre.sql

@@ -11,46 +11,6 @@
 \c regression;
 \i test_gpdb_pre_drop_partition_indices.sql;
 
--- We currently have a bug where a heap partition that is exchanged out of the
--- partition hierarchy is not given an array type. When this table is restored
--- in the new database, it will be given an array type -- but there will be no
--- preassigned OID for it, so it'll steal one from the pool. If some other
--- object collides with that stolen OID, upgrade will fail.
-CREATE OR REPLACE FUNCTION drop_heaps_without_array_types() RETURNS void AS $$
-DECLARE
-	broken_table RECORD;
-	sql TEXT;
-BEGIN
-	FOR broken_table IN
-		SELECT n.nspname, c.relname
-		  FROM pg_class c
-		  JOIN pg_namespace n ON (n.oid = c.relnamespace)
-		  JOIN pg_type t ON (t.typrelid = c.oid)
-		  LEFT JOIN pg_type arr ON (arr.typelem = t.oid)
-		  LEFT JOIN pg_partition_rule pr ON (pr.parchildrelid = c.oid)
-		WHERE
-		  -- heap relations only
-		  c.relstorage = 'h' AND c.relkind = 'r'
-		  -- that aren't subpartitions
-		  AND pr.oid IS NULL
-		  -- and that aren't catalog tables
-		  AND n.nspname NOT IN ('pg_catalog', 'pg_toast', 'pg_aoseg',
-							    'pg_bitmapindex', 'gp_toolkit', 'information_schema')
-		  -- with no array type
-		  AND arr.oid IS NULL
-	LOOP
-		sql := 'DROP TABLE ' || quote_ident(broken_table.nspname) || '.' || quote_ident(broken_table.relname) || ' CASCADE';
-
-		RAISE NOTICE '%', sql;
-		EXECUTE sql;
-	END LOOP;
-	RETURN;
-END;
-$$ LANGUAGE plpgsql;
-
-SELECT drop_heaps_without_array_types();
-DROP FUNCTION drop_heaps_without_array_types();
-
 -- This one's interesting:
 --    No match found in new cluster for old relation with OID 173472 in database "regression": "public.sales_1_prt_bb_pkey" which is an index on "public.newpart"
 --    No match found in old cluster for new relation with OID 556718 in database "regression": "public.newpart_pkey" which is an index on "public.newpart"