Direct Erlang client connections (e.g. those used by shovel) cannot be deserialized

[jacob-84Codes]

Describe the bug

When using the list connections command, if there is a shovel present in the instance, an error occurs:
HTTP API request failed: error decoding response body
This error occurs from attempting to tabulate the JSON that the rabbitmq API provides for a shovel which is markedly to other connections.

When rabbitmqadmin tabulates a connection it lists the: name, node, state, protocol, username, connected_at, server_hostname, server_port, client_hostname, client_port, channel_max, and channel_count. Of these categories, the JSON for a shovel connection only provides the name, node and protocol, causing the error as the response is missing a lot of information needed for the tabulation.

Shovel connections JSON:

Vs standard connection JSON:

Reproduction steps

1. On a rabbitmq instance without a shovel, test that 'rabbitmqadmin list connections' works
2. Add a shovel connection to the instance
3. Run 'rabbitmqadmin list connections' again and confirm that it no longer works

Expected behavior

I can see two different possible expected behaviours. The first would be to alter the tabulation to provide a default 'N/A' value when a value is missing when listing connections. The other option would be to ignore connections that would otherwise cause this error to occur, along with a notification that connections had to be excluded and a list of just the names of these connections.

Additional context

No response

[michaelklishin]

Connections that use the direct Erlang client, such as shovels and federation links, cannot be rendered by rabbitmqadmin at the moment.

Skipping connections is certainly not what the user expects. Rendering direct client connections will require turning the connection struct into an enum of options that are serialized differently, and rendered to the table differently.

@jacob-84Codes since 84codes directly makes money off of RabbitMQ and contributes very little back, you are welcome to contribute your fair share.

[michaelklishin]

What today is a Connection struct would have to become a ClientOrDirectConnection, an enum, that would use serde(untagged) and have two versions, a ClientConnection identical to the Connection that exists today, and another, a DirectConnection or something like that, with a lot fewer fields.

ClientCapabilities and such won't change because a lot of their fields already use defaults (or are optional).

[michaelklishin]

Making a few fields an Option<T> turned out to be a sufficient, and much simpler, option than a union type/enum with a Tabled implementation.