[PATCH] Report changes discarded for relations not in the subscription

Hi,

I encountered an issue after a pg_upgrade of a subscriber instance.
pg_subscription_rel came back empty, and the apply worker then discarded
every incoming change while the replication origin and the publisher
slot's confirmed_flush_lsn advanced past the discarded rows. Both ends
durably recording the transactions as applied, with nothing in either log
to say otherwise.

a relation that is not SUBREL_STATE_READY
is skipped with no log message at any elevation, no conflict and no
statistics counter. That is correct while a tablesync worker is still
copying the table, but it is indistinguishable from a relation with no
pg_subscription_rel row at all, where the discard is permanent. The
latter also occurs in ordinary operation, whenever a table is added to a
publication and the subscriber has not refreshed.

Behaviour is unchanged and the patch only
adds debug logging, so that the discard is visible and the two cases can
be told apart.

- DEBUG1 when the relation is not part of the subscription, separating
"the subscription has no tables at all" from "this one relation is not
in the subscription", each with a hint pointing at
ALTER SUBSCRIPTION ... REFRESH PUBLICATION.

- DEBUG2, with sync state and LSNs, when the relation is merely not
synchronized yet.

log_min_messages = debug1 for a minute then names the relation and tells a
lost table list apart from a missing REFRESH -- two conditions with
different fixes that the server currently cannot distinguish.

Reporting is throttled per relation. Basically a sync state change is reported
immediately, otherwise at most one message per
wal_retrieve_retry_interval, which is already the retry throttle for this
subsystem in syncutils.c and launcher.c and has a minimum of 1 ms, so
unlike a wal_receiver_timeout of 0 it cannot disable the throttle. The
throttling state lives in LogicalRepRelMapEntry, so this is HEAD-only.

A TAP test is included in 024_add_drop_pub.pl for the published-but-not-
refreshed case, asserting both the message and that it is emitted once
rather than once per row.

Demir.