Re: Crashes on a partition whose concurrent detach never finished

Hello, everyone!

Thanks to Amit for pushing, and to others for new findings and reviews.

Attached is v2 of the remaining fixes, rebased on master and
registered in the commitfest as [3] for tracking purposes.

I tried to combine everything into the series. It is mostly
AI-generated, but I still think structuring everything is helpful
anyway.

The rule throughout is that a partition pending detach is published as
a standalone table, as it will be after FINALIZE; publishing it via
the former root would cause the divergence Nisha described in [1].

0001 (pgoutput crash): The test comment Shveta asked about was
misleading; it's fixed. pgindent-clean applied.

0002 (identity sequence) gains a new test: an insert into a leaf under
a partition pending detach still finds the root's sequence.

0003 is Zsolt's fix for the inconsistency Shveta pointed out:
pg_get_publication_tables() now lists a partition with no active
ancestors, so REFRESH PUBLICATION can pick it up before FINALIZE.

Tests moved to 100_bugs.pl to reuse infra from 0001 (AI-generated).

The commit message now also says, as Nisha found in [2], that the full
list has been affected since 14, while the targeted lookup only exists
in 19.

0004 is Shveta's invalidation, which I (mostly AI) finished up a bit.
It also invalidates the descendants of a partitioned partition, as
Nisha suggested in [1], and locks them with AccessShareLock.

[1] https://www.postgresql.org/message-id/CABdArM4fJ8JAWyP0MAF%3D8n66M6%3DCouUmtSGwqizn2pD%3DgfPEZw%40mail.gmail.com
[2] https://www.postgresql.org/message-id/CABdArM7Bc7SZPSHk5uT-yA6%3DDYVFW-Os4noB6CANH6GQw9rvew%40mail.gmail.com
[3] https://commitfest.postgresql.org/patch/7351/

Best regards,
Mikhail.