FD_SOCK socket-binding client mappings do not map to external_addr/port properly

The JGroups FD_SOCK protocol requires 2 TCP sockets. Older versions of WildFly accepted a socket-binding for this protocol, but that was removed around version 11, apparently because the binding's port number wasn't actually used.

Now the port selection is random by default, which is a problem if you've got firewalls to deal with, as noted in the linked document. The suggested workaround is to set the client_bind_port and start_port properties of the protocol, but that has the drawback of not being affected by a socket-binding-group's port-offset. This means that if you want to run 2 WildFly instances on the same box with the same config (which I do, as a developer, to test application code related to clustering), simply changing the port offset is insufficient to get the second instance to start.

So I'd like to suggest that socket-binding for FD_SOCK be resurrected, given that it can be implemented correctly now. FD_SOCK calls the configured SocketFactory for both the server socket (with name jgroups.fd_sock.srv_sock) and the client socket (with name jgroups.fd.ping_sock), so it should be possible for WildFly to fully manage the socket bindings.