Add a new flag in remote for connecting through a Unix domain socket.

[Kobaxidze256]

I added a new argument and passed it over to libcurl like how curl's --unix-socket argument works.
Closes #3544.

[LaserEyess]

Codewise this LGTM and how I would have done it. It appears curl is doing the right thing behind the scenes in checking for the socket path length. However, it isn't passing this feedback to the user. Consider this:

$ ./utils/transmission-remote google.com:443 --unix-socket /tmp/transmission.sock -l                                       
    ID   Done       Have  ETA           Up    Down  Ratio  Status       Name
     1   100%    3.12 GB  Done         0.0     0.0   0.00  Idle         ubuntu-21.10-desktop-amd64.iso
Sum:             3.12 GB               0.0     0.0
$ echo $?
0

vs.

$ ./utils/transmission-remote google.com:443 --unix-socket /tmp/transmission.sockasdahdfoasihdfoaishdfoiashdfoiashdfoiahsdofihasodifhasoidfhsssssssssssssssssssssssssssssssssssssssssssssssssss -l
$ echo $?
1

This is not good UI imo, especially given the fact that curl is in fact providing this as feedback:

$ ./utils/transmission-remote google.com:443 -b --unix-socket /tmp/transmission.sockasdahdfoasihdfoaishdfoiashdfoiashdfoiahsdofihasodifhasoidfhsssssssssssssssssssssssssssssssssssssssssssssssssss -l 
posting:
--------
{"arguments":{"fields":["error","errorString","eta","id","isFinished","leftUntilDone","name","peersGettingFromUs","peersSendingToUs","rateDownload","rateUpload","sizeWhenDone","status","uploadRatio"]},"method":"torrent-get","tag":6}

--------
* Couldn't find host google.com in the (nil) file; using defaults
* Unix socket path too long: '/tmp/transmission.sockasdahdfoasihdfoaishdfoiashdfoiashdfoiahsdofihasodifhasoidfhsssssssssssssssssssssssssssssssssssssssssssssssssss'
* Closing connection 0

The second thing to notice from this is that I can use whatever host/port I want and it works, I think that's confusing but truth be told it doesn't really affect anything, --unix-socket is pretty explicit.

Besides that UI nit, I'm wondering long term if @mikedld's was right in #3544. One of my goals if I stop being lazy is to make unix sockets also accept raw JSON instead of using HTTP for rpc. In this case it would make sense to parse unix:// vs http:// or unix+http://. However, the way transmission-remote works right now it doesn't even take http{s,}:// as an argument so that really has nothing to do with this PR. Plus, non-http-rpc is hypothetical at this point so I don't think it should be a blocker.

[Kobaxidze256]

@LaserEyess I don't understand what I should change about the output. Also are the check fails my fault?

[LaserEyess]

The check doesn't fail, it succeeds, but the feedback isn't being given to the user. That's my point. I don't really think it's a dealbreaker, I haven't even looked at how transmission-remote handles other errors from curl.

[Kobaxidze256]

The check doesn't fail, it succeeds, but the feedback isn't being given to the user. That's my point. I don't really think it's a dealbreaker, I haven't even looked at how transmission-remote handles other errors from curl.

Sorry for the delay. Other errors are handled the same way. This seems to be a problem only on the master branch, the last release works fine.