Re: find_all_inheritors() with NoLock fails on concurrently dropped sub-partitions

From the 4 affected callers:
* For LOCK TABLE, it somewhat seems to be a regression caused by b7e51b350c4
* I would have to investigate GetPubPartitionOptionRelations, but I
assume there's some reason why it wants to avoid locking. There's no
comment explaining it, and it's not mentioned in the commit message.
* REPACK/CLUSTER says that it is the same as VACUUM
* and VACUUM explicitly says that it shouldn't lock because locking
could cause deadlocks, it has a long comment about it from
19de0ab23cc:

* Make relation list entries for this rel and its
partitions, if any.
* Note that the list returned by
find_all_inheritors() includes the
* passed-in OID at its head. There's no point in
taking locks on the
* individual partitions yet, and doing so would just
add unnecessary
* deadlock risk.

the same commit message also says this about the issue it fixes:

A concurrent DROP TABLE could now produce "cache lookup
failed", which we don't want to have happen in normal operation.

Which is also the leftover issue caused by the use of
find_all_inheritors with NoLock in the above scenario.

Assuming that the deadlock comment is accurate, that means we can't
use locking find_all_inheritors, and that leaves either accepting the
possible cache lookup failed error or making the NoLock variant
resistent to it. (or inventing a similar different function that does
the same without the cache error)