[PLAT-742] Adds ReconnectCallback to ws go-client

[kschoche]

Adds a ReconnectCallback to the websocket go-client, useful for client side management of reconnects which are otherwise not exposed to the user.

The new callback functionality can be consumed similarly to the way it is used in the unit tests or similarly to this:

	reconnectCallback := func(err error) {
		reconnectCounter++
		if err != nil {
			logger.Errorf("unable to reconnect, retrying %d: %v", reconnectCounter, err.Error())
		} else {
			logger.Info("reconnect successful")
		}
	}

	client, err := polygonws.New(polygonws.Config{ReconnectCallback: reconnectCallback,   ...})

[jbonzo]

lgtm. Might want to get someone else's review as well, someone not on our team to get a different perspective

[justinpolygon]

Hey @kschoche, thanks for submitting this pull request to add the ReconnectCallback functionality! It's great to see contributions that aim to extend flexibility and control. This could be really helpful for providing more transparency and customization in how reconnections are handled, such as allowing for custom logging, error handling, or even modifying reconnection strategies.

Could you share a bit more about the specific scenarios or issues that prompted this addition? For instance, were there cases where the existing auto-reconnect functionality wasn't meeting certain needs, or perhaps you've encountered situations where additional control over the reconnection process would be beneficial? I'm just wondering if we need to adjust the default reconnection behavior based on what prompted this.

[justinpolygon]

LGTM

[kschoche]

Could you share a bit more about the specific scenarios or issues that prompted this addition? For instance, were there cases where the existing auto-reconnect functionality wasn't meeting certain needs, or perhaps you've encountered situations where additional control over the reconnection process would be beneficial? I'm just wondering if we need to adjust the default reconnection behavior based on what prompted this.

Thanks @justinpolygon!
This is mostly just to expose the reconnect process a bit to the user for logging and metrics, and giving insight into whether or not they are stuck in a retry loop, or e.g. why the reconnect may have failed.