Unexpectedly irreversible foreign key - many local tables added

Hi, this is rather a usability, not a correctness issue. Observed in our production on 11.1 but AFAICT Citus behaves the same in 11.2.

We have a somewhat large Postgres database (a few TBs). We've moved a few of the largest tables into Citus. So far we avoided Citus-local tables because we saw problematic behaviour such as #6729. Recently, we've accidentally added a foreign key between a plain Postgres table and a reference table. This led to a cascade which moved a few hundreds of tables into Citus metadata. I haven't found a supported way to revert this operation. Dropping the problematic foreign key calls the equivalent of `undistribute_table` that tries to copy all data. That is prohibitively slow for us.

The unexpected behaviour therefore is that a *quick operation that doesn't use any Citus function* cascades to change behaviour of many tables and there is no easy way back.

Possible options that could improve usability in my opinion:

- Make Citus-local tables really equivalent to plain Postgres tables. I read in the 11.0 release notes that this is your goal but I couldn't find any mention of the parallel/serial issue in #4145.
- Make the operation reversible - that is optimize `undistribute_table` in the case of local tables to just drop the shell table and revert the renames.
- Somehow require confirmation (a new PG variable?) before adding the index that would cause the cascade.

Best regards!