Ensure no reconnect happens after destroy()

[selfcontained]

The purpose of this PR is to ensure if someone calls destroy() on their worker instance, it won't reconnect. Calling destroy() already cancels any pending reconnect attempts, but there's a small chance that the start.rtm api call was already issue, but hasn't received a response yet. In this case what happens is the worker closes out the current RTM connection and cancels any queued up reconnect attempts. It doesn't currently handle a case where the callback from the rtm.started api call comes back after destroy() was called.

I added a flag to track the state of if the worker has been destroyed - and then make sure to check that prior to creating the websocket connection for the RTM. This prevents the case described above.

We've run with this particular patch on a bot with about 60 teams connected and it's resolved issues they've had related to this bug (they would end up with 2 RTM connections to a team when trying to manually destroy a worker instance, and create a new one).

[mbrevoort]

This is really a bug fix rather than an enhancement. It's affecting multiple Beep Boop users, would love to get this merged! 🙏

[anonrig]

Nice catch!