chore: ensure that we can dial tls multiaddrs

[danisharora099]

Problem

js-waku is currently unable to dial a new format of secure websocket multiaddrs denoted by /tls/ws instead of wss
it was seen that js-libp2p supports these multiaddrs and that the bug actually came from an older version of @multiformats/multiaddr-to-uri which is specified in @libp2p/websockets

relevant issue on js-libp2p: libp2p/js-libp2p#2024

a PR was opened to upgrade the version of the faulty dependency which did not support tls format multiaddrs at the time but was discarded as the solution given was to update the lockfile: libp2p/js-libp2p#2059 (comment)

Solution

• added a test for tls mutliaddrs
• generated a fresh lock file

Notes

• with the old lockfile, it can be seen that when the test is added, it actually fails (https://github.com/waku-org/js-waku/actions/runs/6237429056/job/16931018217?pr=1580)

• when a fresh lockfile is generated, the test passes https://github.com/waku-org/js-waku/actions/runs/6272635285/job/17034532746?pr=1580

• Related to peer-exchange: investigate p2p-circuit address discovery & connection #1527

[github-actions]

size-limit report 📦

Path	Size	Loading time (3g)	Running time (snapdragon)	Total time
Waku core	27.69 KB (0%)	554 ms (0%)	471 ms (+7.4% 🔺)	1.1 s
Waku Simple Light Node	248.68 KB (-5.31% 🔽)	5 s (-5.31% 🔽)	1.1 s (+46.64% 🔺)	6 s
ECIES encryption	28.7 KB (0%)	574 ms (0%)	318 ms (+1.87% 🔺)	892 ms
Symmetric encryption	28.7 KB (0%)	575 ms (0%)	460 ms (+72.69% 🔺)	1.1 s
DNS discovery	110.62 KB (0%)	2.3 s (0%)	447 ms (-29.34% 🔽)	2.7 s
Privacy preserving protocols	117.02 KB (-0.32% 🔽)	2.4 s (-0.32% 🔽)	594 ms (-9.02% 🔽)	3 s
Light protocols	25.83 KB (0%)	517 ms (0%)	364 ms (-9.96% 🔽)	881 ms
History retrieval protocols	24.9 KB (0%)	499 ms (0%)	283 ms (-15.21% 🔽)	781 ms
Deterministic Message Hashing	5.65 KB (0%)	113 ms (0%)	74 ms (-45.07% 🔽)	187 ms

[weboko]

Isn't it always instance of Error?

[danisharora099]

not necessarily; Error is the most common way of throwing but one can throw literally anything

• number: throw 404
• boolean: throw false
• string: throw "this is an error message"
• object: {error: "this is an error message"}
• ...

[weboko]

with the old lockfile, it can be seen that when the test is added, it actually fails (https://github.com/waku-org/js-waku/actions/runs/6237429056/job/16931018217?pr=1580)

when a fresh lockfile is generated, the test passes https://github.com/waku-org/js-waku/actions/runs/6272635285/job/17034532746?pr=1580

I still didn't debug it but it seems that package-lock of old version resolves to old versions of packages and usually it happens when there are packages in monorepo that have different versions of the same package. Not sure if it is the case here but re-generating the lock is enough.