Return rtm.start API response to callers of rtm_connect()

[Terrance]

• I've read and understood the Contributing guidelines and have done my best effort to follow them.
• I've read and agree to the Code of Conduct.
• I've searched for any related issues and avoided creating a duplicate issue.

Description

The rtm.start API method returns a lot of useful information, which would otherwise require multiple API calls to retrieve. Currently SlackServer.rtm_connect() discards it all, and SlackClient.rtm_connect() just returns a bool for whether the connection succeeded. It would be more useful to return the whole response (login_data in this case) for further processing.

This would affect the method signature, but is effectively backwards-compatible for callers that just test truthiness of the result.

/cc #50 and #175, which allow raising an exception on failure -- I think a nice solution would be a combination that either returns the full dict on success, or raises an exception on failure.

Reproducible in:

• This is reproducible in the sample project.
  python-slackclient version: current master

Expected result:

>>> SlackClient(...).rtm_connect()
{'ok': True, 'url': 'wss:\\/\\/ms9.slack-msgs.com\\/websocket\\/7I5yBpcvk',
 'self': {...}, 'team': {...}, 'users': [...], ...}

Actual result:

>>> SlackClient(...).rtm_connect()
True

[emersondispatch]

👍 the opaque connection failure makes it difficult for our application to know what to do next. Even just the status_code would be a really useful improvement

[simonfiddaman]

I wouldn't change from rtm.connect to rtm.start because of the sheer volume of data returned on rtm.start (especially for those using Enterprise Grid - there could easily be 10,000+ users there), but I 100% agree - discarding the data returned (i.e. the BOT ID!!) removes the ability for the bot to work out its own ID (assuming you're using natural language to interact with it, like hey @bot what is the time?.

EDIT: oh, I see it's still rtm.start and #190 is changing that.

[RodneyU215]

Thanks for all of the feedback. I'm closing this issue as we're no longer adding client enhancements in v1. Going forward all client enhancements will be implemented in v2. For this request in particular we've made the entire RTM payload available to you during the open event when connecting to RTM. Please see #384 for more details.