pass *url.URL to ConnectPacketBuilder

[XANi]

As per discussion in #192 I've added URL as a parameter, and also an example on how to use it to extract password from URL

[MattBrittan]

I wonder if we should pass a struct instead? Trying to think of any other data that might be of use to ConnectPacketBuilder in the future (using a struct would mean future additions would be non-breaking) but cannot currently think of anything else that would be useful...

[MattBrittan]

Probably fine as is (unless you can think of other data that could be useful).

[XANi]

It could just be passed entire ClientConfig, although only other useful thing to configure before connection that I can think of is TLS configuration and it's too late for that in buildConnectPacket

[XANi]

But URL is really only thing different between each connection attempt so any other external info user might want in that function could just be provided by the user when defining the function. Nothing really stops hook from looking like this

config := autopaho.ClientConfig{
		ServerUrls:        []*url.URL{serverURL},
		ConnectRetryDelay: 5 * time.Second,
		ConnectTimeout:    5 * time.Second,
		ClientConfig: paho.ClientConfig{
			ClientID: "test",
		},
	}
config.ConnectPacketBuilder = func(c *paho.Connect, u *url.URL) *paho.Connect {  
    doSomethingWith(config)
}

[MattBrittan]

Yea, something to do with the TLS connection (or the net.Conn itself) was what I was thinking of. However having thought of this I could not come up with a real use-case...

[XANi]

Well the simplest one would be different server cert/client cert/ca per server but if ever someone had that use case AttemptConnection hook can cater for that just fine.

I guess one thing that could be improved is making attemptXXXConnection() functions public so someone making custom AttemptConnection hook could reuse it, I can add a commit changing it here if you want.

[MattBrittan]

Thanks - however I feel that the attemptXXXConnection functions are pretty simple & generic (also easy to copy/modify) so it's best to leave them private (making them public may make future changes more difficult because changing a public interface = breaking change).

[XANi]

Yeah I suggested it because the packets.NewThreadSafeConn() in attemptTLSConnection might be not very obvious on first look but the comment on callback itself explains it well enough

[MattBrittan]

I don't think we should change this; it's an unnecessary breaking change to a depreciated function. Just wrap the function the user passed.

[XANi]

fixed