#61 emit prettier URLs in logging output

[Tom Kralidis]

Very cosmetic request: when reviewing sr_subscribe logs, lines displaying the source of data display the hostname and ensuing path space seperated, like:

2016-11-10 00:00:19,959 [INFO] Received notice  20161110000019.523 http://dd3.weather.gc.ca/ citypage_weather/xml/BC/s0000106_e.xml
2016-11-10 00:00:19,959 [WARNING] sr_message checksum_match file not big enough (insert?)
2016-11-10 00:00:19,965 [INFO] 201 Downloaded : v02.log.citypage_weather.xml.BC.s0000106_e.xml 20161110000019.523 http://dd3.weather.gc.ca/ citypage_weather/xml/BC/s0000106_e.xml 201 geomet-de
v-02.cmc.ec.gc.ca anonymous 0.440805 parts=1,15560,1,0,0 sum=d,72aea7bd383fec8ae546e3a4e89bd6a6 from_cluster=dd.weather.gc.ca source=dd-xml-inotify rename=/data/geomet/amqp/citypage_weather/xm
l/BC/s0000106_e.xml message=Downloaded

I'm not sure if this is by design, however it would be valuable to have the host/path output like:

http://dd3.weather.gc.ca/citypage_weather/xml/BC/s0000106_e.xml

which makes review/triage easy when doing copy/paste of URLs.

[psilva]

What is being printed is the actual content of the message, it isn't formatted at all.
the reason for the separation was that it was initially supposed to separate the static part of the URL from the dynamic one... kind of the 'root' of the subscription is on the left, and the dynamic part that could change entirely was on the right... so if there was a server where all the content was offset to a sub-directory, then the static root would be on the left...

ie.
http://server/sarra-root/ relative_path/A/B/C.txt

Without this separation, there would be no way to identify which part of the tree was static, and where to build the tree from. In the implementation, it got mangled into presenting the server part of the URL on the left, and the entire path on the right... and we added skip... so it isn't clear if so the reason for the separation is now moot, but that's v02 version of the messages.

This is likely all internal trivia that users likely don't care abou ... 99% of users will not care what the protocol payload looks like. So changed the log messages where relevant.... some debugs left alone,

commit: 7864bf894bf6e7da230bff4181f264acd5126289

[psilva]

note that while the previous format was independent of changes in the message format, future versions of messages will now be broken. (ie. if v03 changes for format of the messages... which is pretty likely... all these printouts will need to be reviewed.)