[wsclient] Allow for Embedded Basic Auth in URLs

[onelapahead]

We observed when using the wsclient package that if a WS URL had basic auth embedded in it we'd get the following error:

Kaleido Block IndexerCopyright (C) 2023 Kaleido
Version:  (Build Date: 2023-11-16T19:49:14Z)

time="2023-11-20T20:14:29.999Z" level=info msg="[i] No TLS configuration provided`"
time="2023-11-20T20:14:29.999Z" level=debug msg="Created REST client to https://user:pass@acme.com"
time="2023-11-20T20:14:29.999Z" level=warning msg="WS wss://user:pass@acme.com connect attempt 1 failed [-1]: "
time="2023-11-20T20:14:29.999Z" level=fatal msg="[!] Failed to connect to blockchain : FF00148: Websocket connect failed: malformed ws or wss URL"

In some cases, applied configurations are more difficult to change than a binary version. This change proposes that the credentials in the URL be handled more gracefully, in that 1) the embedded credentials are always removed from the URL string, and that 2) if the config did not have auth credentials provided, the embedded credentials are extracted and used automatically.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (27e89cb) 100.00% compared to head (e3aa13f) 99.98%.
Report is 46 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff             @@
##              main     #111      +/-   ##
===========================================
- Coverage   100.00%   99.98%   -0.02%     
===========================================
  Files           63       77      +14     
  Lines         5048     6170    +1122     
===========================================
+ Hits          5048     6169    +1121     
- Misses           0        1       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[nguyer]

Looks good to me. @peterbroadhurst I don't know if you want to look at the UT changes here that I made (doesn't seem right for me to approve my own changes). Essentially when running in GitHub actions, the file watcher would fail to start because the file didn't exist yet. This seems to work fine running locally, and the way the test was written it seemed like that's exactly what it was designed to test. But it doesn't work. I re-arranged the test so that the file is there when the watcher starts. But I wanted to make sure I wasn't just patching a test to cover up an actual bug.