Use builder pattern to construct WebRtcSocket

[garryod]

Had a go at creating a builder for the WebRtcSocket to replace WebRtcSocketConfig, this should make things a touch easier when it comes to constructing sockets with numerous channels.

Also added a helper to the ggrs feature to allow users to more easily add an appropriate channel.

[nuzzles]

Please add WebRtcSocket::builder() -> WebRtcSocketBuilder

[garryod]

Please add WebRtcSocket::builder() -> WebRtcSocketBuilder

Good idea! Have used the same arguments as WebRtcSocketBuilder::new, but not sure this feels quite right

[nuzzles]

Brilliant.

[johanhelsing]

Look good now :) I only had a doc nit and a question.

[johanhelsing]

Oh, I'd still like some dead-simple convenience methods that doesn't involve creating a builder.

let socket = WebRtcSocket::new_unreliable("wss://example.com");

As opposed to:

let socket = WebRtcSocket::builder("wss://example.com")
    .add_unreliable_channel()
    .build();

Internally, it would just call the builder.

I want to keep simple/common usage really simple as far as possible.

[garryod]

Oh, I'd still like some dead-simple convenience methods that doesn't involve creating a builder.

Done! Do you think we should use these or the builder in the examples?

[johanhelsing]

Oh, I'd still like some dead-simple convenience methods that doesn't involve creating a builder.

Done! Do you think we should use these or the builder in the examples?

Hmmm.. I think it would be good to have at least one example that shows how to set up multiple channels, but in our current examples i think the simple versions are probably better.

[garryod]

Hmmm.. I think it would be good to have at least one example that shows how to set up multiple channels, but in our current examples i think the simple versions are probably better.

That seems reasonable to me, a mutli-channel example would definitely be good to have

[nuzzles]

Not really convinced, wouldn't we have to add a lot of API: ip/hostname, port, which ws and wss, path and query string building? Only to convert it to a string since that's what the browser/async_tungstenite wants anyway... I think we should just wrap WsErr::InvalidUrl (and the native variant) into one of our errors when connecting.

Ok, I think it clicked for me when you said "that's what the browser wants anyways".

Fair point.

[johanhelsing]

Alright, let's get the money! 🎉