Support exponential backoff for reconnects

[ViToni]

Is your feature request related to a problem? Please describe.
When there is a large number of clients and there is some kind of synchronization event (e.g. broker restart, update, etc.) the reconnect will trigger a reconnect storm.

Describe the solution you'd like
I'd like to be able to provide a "backoff strategy".
For mass-clients it could implement an exponential backoff, for some e.g. some kind of backend service it could use a fixed value similar to what we have right now.
Both strategies could be implemented as generic solutions which would allow user to customize then according to their needs / infrastructure abilities.

Describe alternatives you've considered
A rate limiter on the broker side sure helps but is more of an add-on than an alternative to a backof strategy.

Additional context
No additional context.

[ViToni]

If the general idea is okayish I can work on a PR for this feature.

[MattBrittan]

Sounds good, as long as it does not add too much complexity. I'd prefer to keep the number of options well below paho.mqtt.golang which tried to do everything, autopaho should meet the needs of most users and act as a starting point for more complex needs. Having said that, I think this would be a useful addition (should probably depreciate ConnectRetryDelay if this is implemented).

Might be worth looking at the paho.mqtt.golang functionality (but it's probably better to use an interface and allow users to override the default controller).

[ViToni]

As I had some similar functionality written once for a Java project I tried to somehow transfer it to Go.
So if I hit any no-Go-s please bear with me, it's my first non-Hello-World Go code.