Use pg_local to track AMQP 1.0 connections

[lukebakken]

Fixes #9371

Since each AMQP 1.0 connection opens several direct AMQP connections, we
must assign each direct connection a unique name to prevent multiple
entries in the connection_created_stats table.

Also, use pg_local to track AMQP 1.0 connections instead of walking
the supervisor trees.

[ansd]

Why is pg_local moved to rabbit_common?
rabbit_common is for code common between rabbit and AMQP 0.9.1 client.

[lukebakken]

Why is pg_local moved to rabbit_common? rabbit_common is for code common between rabbit and AMQP 0.9.1 client.

Did we change the "rules" when it comes to sharing code between sub-projects in deps/? As far as I know, plugins can't use code in deps/rabbit. cc @dumbbell

The rabbitmq_stream plugin also uses pg_local which is "against the rules". At least, the last time I dealt with something like this.

[dumbbell]

Did we change the "rules" when it comes to sharing code between sub-projects in deps/? As far as I know, plugins can't use code in deps/rabbit. cc @dumbbell

That's the opposite: plugins must depend on rabbit. We should not add code to rabbit_common unless the amqp_client needs it. Otherwise, the client inherits everything the server depends on.

There are still many circular dependency problems around rabbit_common, mostly because of the "direct connection" feature of amqp_client which requires a (too) deep knowledge of the server.

As amqp_client almost never evolves, we should basically never add code in rabbit_common.

[ansd]

1.)
I like the idea of using a separate process group for AMQP 1.0 connections. We likely need such a process group for Native AMQP anyway.
However, I would prefer to use local only pg as done for Native MQTT instead of pg_local. pg_local becomes a bottleneck as shown in https://github.com/rabbitmq/mqtt-testing/tree/79329012092f9b77f3663086a590b4631cb812a9/one-to-one#mass-client-disconnection
However, I could also to this changes as part of #9022. I don't think scalability matters much for non-native AMQP as shown by the supervisor:which_children/1 calls prior to this PR.

2.)
Closing the connection via the management UI shows inconsistencies in the AMQP 1.0 connections.
To repro:

1. Create an AMQP 1.0 connection.
2. You will see that connection the Management UI
3. Force Close that connection from the Management UI.
4. The Management UI will not show the connection.
5. However, rabbitmqctl list_amqp10_connections will still show the connection.

From my point of view, this bug is acceptable for now, I'll fix it for 4.0 as part of #9022

[ansd]

Tests are failing.

[michaelklishin]

Looks like the

bazel test //deps/rabbitmq_amqp1_0:proxy_protocol_SUITE

failures are consistent.

[lukebakken]

@michaelklishin I'm working on it!

[lukebakken]

@ansd @michaelklishin this should be good to go after the next CI round.

[michaelklishin]

Expanding the list of columns we return for AMQP 1.0 connections would be very nice but this (avoiding crashes and querying supervisors for children) is definitely an improvement as is.