Adapt to Slack API changes

[binaryseed]

This PR makes a few changes to adapt to Slack API changes...

• It extends the handle_connect callback to enable initializing both the slack and process_state
• Connect via the rtm.connect instead of rtm.start API
• The HTTP client is set to :atom keys since that's what everything inside this library already expects

Some docs changes are likely in order, and can be added...

fixes #233

[binaryseed]

Ok, so maybe make this configurable? Or perhaps this is a major version bump?

[binaryseed]

Another possibility is to make this "forward compatible" by using rtm.connect doing all the init lookups that rtm.start used to include...

[acconrad]

@BlakeWilliams I had proposed a major version bump back last time - is this the point we make the cutoff?

[BlakeWilliams]

Since we're below 1.0, we can technically make breaking changes at any time. Although I'd prefer we don't make breaking changes when we can avoid them.

I think the best way forward is supporting both approaches since I think some bots will currently rely on the old behavior still being present. But we could recommend the new approach over the old one in the README and documentation. If we want to move towards a 1.0 release, I think an issue tracking some of the required work would be great 👍

[parkerjm]

Hey guys, any movement on this? The library currently doesn't work for any bots/apps created after November 2021, as the rtm.start endpoint returns an error for any new bots/apps. I had to create an altered version of this lib in order to get my new bot to work. I was about to submit a PR when I found this one.

Maybe the lib could attempt to connect to rtm.start, detect the deprecation error, and connect to rtm.connect instead.

[parkerjm]

FYI, slack has stated:

For existing apps, rtm.start will start behaving exactly like rtm.connect on September 20, 2022.

https://api.slack.com/changelog/2021-10-rtm-start-to-stop

[peixian]

Is there a blocker for this PR to get upstreamed?