RFC: Web API error response_metadata is buried

In some of the more recent Web API methods the most relevant error information is given in the response_metadata. For instance here's an example of Slack's response body for a bad call to views.open:

{
  "ok": false,
  "error": "invalid_arguments",
  "response_metadata": {
    "messages": [
      "[ERROR] missing required field: title [json-pointer:/view]",
      "[ERROR] missing required field: blocks [json-pointer:/view]",
      "[ERROR] missing required field: type [json-pointer:/view]"
    ]
  }
}

The error value of invalid_arguments is basically useless on its own — it's necessary to look at the response_metadata to understand the problem with the request.

Currently this library pulls out the error value and uses this for the message on SlackError (here). It's possible to access the reseponse_metadata with slack_error.response.body.response_metadata. However my problem is that when an error is raised my logs only show the error, because that is the message (and as far as I can tell, raise prints Class: message).

My goal is to get the response_metadata into my logs. Here's one idea that I have for a feature in this library that would achieve that:

1. Add a config option for verbose Web API errors (verbose_web_api_errors?).
2. If this config option is set then the message on SlackError will be the entire body as JSON, rather than just the error.
3. The option would default to false so as to not break anyone's code.
4. SlackError would also gain a new attribute, perhaps error, which would be the value of error from Slack's response, so that this is easily accessed even when the verbose option is being used.
5. For completeness, SlackError would also gain a new attribute response_metadata containing just the response_metadata (as a hash-like object).

What do you think of this approach? I don't know much about logging, so maybe there's a better approach to this, either within this library or simply in my own app.

Start by reading lib/slack/web/faraday/response/raise_error.rb, where the response error becomes the SlackError message, and inspect how response.body is exposed. The issue proposes several possible API and configuration changes, so first confirm the desired behavior with maintainers; done would require an agreed design and corresponding coverage for verbose messages and response attributes.