Use user specified connection name in logs

[binarin]

In addition to rabbitmq/rabbitmq-server#104

[michaelklishin]

As far as I see this replaces connection name with a user-provided one. We cannot do this because TCP socket-based names also provide valuable information (and are used in the HTTP API).

We should append user-provided names to the socket-derived ID.

[binarin]

It's actually appended, like this - <<Name/binary, " - ", UserSpecifiedName/binary>>. I decided to do it that way, because adding new field to #connection{} would also require updating all logging statements.

[binarin]

Also I didn't think about management plugin - with this patch there is no need in special handling of custom connection name, it is automatically shown as a part of name.

[binarin]

Looks like this patch is not that useful in current form, exception logging is using old name.

[michaelklishin]

@binarin I personally would simply update a few call sites that log connection events. That's where most of the value is compared to what we have today.

[binarin]

Updated the patch - looks like this is the only simple way to log something useful. Because adding field to #connection{} will require moving exception handling into mainloop/recvloop.

[michaelklishin]

Sorry but we cannot merge this as is. This changes connection name internally and thus connection ID as reported by the management UI, for example:

[
    {
…
        "client_properties": {
            "capabilities": {
                "authentication_failure_close": true,
                "basic.nack": true,
                "connection.blocked": true,
                "consumer_cancel_notify": true,
                "exchange_exchange_bindings": true,
                "publisher_confirms": true
            },
            "connection_name": "Bunny REPL 1",
            "information": "http://rubybunny.info",
            "platform": "ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-darwin15]",
            "product": "Bunny",
            "version": "2.5.0.pre"
        },
…
        "name": "127.0.0.1:49991 -> 127.0.0.1:5672 - Bunny REPL 1",
…
        "user": "guest",
        "vhost": "/"
    }
]

[michaelklishin]

…and this will definitely break some monitoring tools in ways that we cannot foresee. Maybe a more significant set of changes for 3.7.0 is what we should do instead.

[binarin]

Will it be accepted as-is to master? If not, what are the requirements to make it suitable for either stable or master?

[michaelklishin]

Connection IDs as used by the HTTP API stay unchanged.