fix: fixes #86, client port bungle

[shellscape]

This PR contains a:

• bugfix
• new feature
• code refactor
• test update
• typo fix
• metadata update

Motivation / Use-Case

Fixes #86. Looks like the logic around spinning up servers and passed port.client values got a little bungled.

Breaking Changes

None

Additional Info

None

[shellscape]

@MatTheCat check this out and see if it does the trick for you. I added some additional tests around this stuff to make sure it doesn't get fudged in the future.

[MatTheCat]

Now client port is rigtly used but I can't access the WebSocket server; don't know if it's related.

[shellscape]

Well changing the client port is only for people who have proxies in place to handle that scenario. If you've specified a different client port, you're going to have to make sure that your setup can support that. It's an advanced setting for specialized environments, and there's no way for the module to know if an environment is setup correctly to handle it.

[MatTheCat]

I think I don't understand host.server. Setting 127.0.0.1 or localhost didn't do the trick but 0.0.0.0 works 🤔

[shellscape]

host.server is to setup the host on which the WebSocket server will bind to. It really depends on your environment setup (and whether or not there's a proxy/reverse proxy, etc) for what value to use there. If 0.0.0.0 works then you might have a setup issue with the environment you're running this stuff in.

[shellscape]

@MatTheCat back on topic though - the port issue you described is fixed with this PR though, yes?

[MatTheCat]

Okay using the docker container host works 🎉

So the issue is indeed fixed.