Update: Backported in #2013

The following patch allows the following hostname subscriptions:

--subscribe-to NODE_HOSTNAME:3031=ROUTER_HOSTNAME:2626:FASTROUTER_KEY
--subscribe2 addr=NODE_HOSTNAME:3031,server=ROUTER_HOSTNAME:2626,key=FASTROUTER_KEY

instead of manually resolving the IP addresses:

--subscribe-to 10.0.0.2:3031=10.0.0.1:2626:FASTROUTER_KEY
--subscribe2 addr=10.0.0.2:3031,server=10.0.0.1:2626,key=FASTROUTER_KEY

Addresses are resolved by the fastrouter client rather than the server so I didn't have to update the request verification on the server (signing). This also means that new clients can understand hostnames without having to restart the server. If server side address resolution is preferred I can look at updating fastrouter/corerouter, but an initial investigation suggested it was not a simple change.

In addition to above, I also made the following changes:

• I clarified the subscribe-to parsing by noting that addr can actually be specified as long as = isn't the first character of the "named socket" (and as mentioned above I added hostname resolution on that code path). NOTE: should this be updated in the documentation? Currently the docs suggest you need to use subscribe2, but instead of closing the undocumented behavior I updated it to match the handling I was adding to subscribe2
• I updated the variable "socket_name" to "address" in the functions that are populating the uwsgi subscription request buffer so the variable name matches the key being populated ("address").