fix: prevent url.parse to set path option

[robertsLando]

Fixes #1870

[Bacto]

Hi,

This update unfortunately breaks websockets connections when used with paths.

In my case, I connect using the URL wss://<hostname>/ws/mqtt.
With 5.6.1 it works great.
But since 5.6.2 it doesn't connect anymore (it uses path / in place of /ws/mqtt).

Could you have a look at this usecase?

[robertsLando]

I think we need some better tests for this so, since I jump in maintaining this repo I find out the coverage is not that good as each release easily breaks something even if tests are passing 😅 I'm sorry for that and I will fix that tomorrow, feel free to open a PR if you can as the fix is not that hard (just look at my changes here and add the path to options when protocol i ws/wss and a test of course ;))

[ytimenkov]

Yeah... Took me like half an hour to understand how this simple fix added support for unix sockets and how it broke them...

It feels that we mixed 2 different OSI layers: for WebSockets, path is part of application layer (7) while for UNIX it's network address => probably as low as layer 3.

I don't see any good way to disambiguate the grammar except for explicitly state address family (inet(6) vs unix).

Either as git does (git+https) or as a stand-alone option (like curl's --unix-socket). Strictly speaking, you may have WebSocket connection over Unix socket 🤷‍♂️. (However I'm not sure how in this case separate socket path from address..., except for curl's option).

I also think that it is strange that url parsing library which you use yields / path for ipv6 address and undefined for ipv4.

[robertsLando]

@ytimenkov I think it could make sense to add an option on mqtt client to explicitly say when you want to connect to a unix socket ot not, like isUnixSocket so this would be much more easy to handle.

I have drafted a PR here: #1874

But that's without that option, I would like to know your opinion about the new option and if we agree I can add that