RFC: Deadlock detector hooks for edge injection

Hi all

Related to my other post about deadlock detector hooks for victim
selection, I'd like to gauge opinions here about whether it's feasible to
inject edges into the deadlock detector's waits-for graph.

Doing so would help with detecting deadlocks relating to shm_mq waits, help
with implementing distributed deadlock detection solutions, make it
possible to spot deadlocks relating to condition-variable waits, etc.

I'm not sure quite how the implementation would look yet, this is an early
RFC and sanity check so I don't invest any work into it if it has no hope
of going anywhere.

I expect we'd want to build the graph only when the detector is triggered,
rather than proactively maintain such edges, so the code implementing the
hook would be responsible for keeping track of whatever state it needs to
in order to do so.

When called, it'd append "struct EDGE" s to the deadlock detector's
waits-for list.

We'd need to support a node representation other than a LOCK* for struct
EDGE, and to abstract edge sorting (TopoSort etc) to allow for other edge
types. So it wouldn't be a trivial change to make, hence opening with this
RFC.

I expect it'd be fine to require each EDGE* to have a PGPROC and to require
the PGPROC for waits-for and waiting-for not be the same proc. Distributed
systems that use libpq connections to remote nodes, or anything else, would
have to register the local-side PGPROC as the involved waiter or waited-on
object, and handle any mapping between the remote object and local resource
holder/acquirer themselves, probably using their own shmem state.

Bonus points if the callback could assign weights to the injected edges to
bias victim selection more gently. Or a way to tag an waited-for node as
not a candidate victim for cancellation.

General thoughts?