Views/tables based on catalog views can cause issues during metadata sync

Citus automatically propagates views that are created on catalog tables/view:

```SQL
SET citus.log_remote_commands TO ON;
create view v1 as select * from information_schema.table_constraints;
....
NOTICE: issuing CREATE OR REPLACE VIEW public.v1 (constraint_catalog,constraint_schema,constraint_name,table_catalog,table_schema,table_name,constraint_type,is_deferrable,initially_deferred,enforced,nulls_distinct) AS SELECT table_constraints.constraint_catalog,
...
```

This makes sense, because the user can also rename the information_schema.table_constraints, such as:
```SQL
ALTER VIEW information_schema.table_constraints RENAME TO another_view;
```

Now, the `v1` still works from the workers and coordinator as well.

But, the caveat here is the metadata sync. Say, you upgrade from Citus 9.5 to Citus 11.3. And, you first upgraded the workers to PG 15. And, while the coordinator is still on PG 14, you run `CALL citus_finish_citus_upgrade()`.

In that scenario, Citus would try to re-create the `information_schema.table_constraints`. That is mostly fine. But, given that PG 15 has an additional column compared to PG 14, Postgres complained:

```SQL
ERROR: cannot drop columns from view
```

We had to upgrade the coordinator to PG 15, then re-run `CALL citus_finish_citus_upgrade()`.