This is a breaking change intended for the v2.0 release, spun off from the discussion in #2902. I am posting this as a bit of a hot take. If this ends up being a discussion about why the ErrDefaultXXX types and the ErrorContext field are actually useful, and we just end up with actual real documentation on these, that would be a good outcome as well.

Overview and rationale

The ErrDefault series of types (ErrDefault400, ErrDefault401, etc.) serve the apparent purpose of allowing to assert on a specific response code (e.g. to handle 404 responses differently from other 4xx/5xx responses). However, because of their design, they often tend to obscure the real underlying error message in many cases, reporting just something like "Method not allowed" instead of the default error string on ErrUnexpectedResponseCode that explains which request failed and includes the actual error message returned by the OpenStack service. A minimal change to fix that would be to make them all generate the same error string as ErrUnexpectedResponseCode, but there is a much easier solution if we allow the change to be properly breaking.

This commit removes the types, and all of the associated boilerplate, and replaces them with a single small helper function for quickly asserting that an error is an ErrUnexpectedResponseCode with a specific response code. A similar design has been in productive use in my Swift client library for several years. The changes to tests demonstrate how to use this function.

This also gets rid of the undocumented and untested ProviderClient.ErrorContext interface that I have legitimately no idea what it's supposed to be good for, besides maybe allowing users to skip the generation of ErrDefaultXXX-type errors. If that's the only purpose, that would be yet more incentive to just get rid of them.

Finally, as a small (but still breaking) change, this removes some newlines from the error messages generated by ErrUnexpectedResponseCode. Newlines in error messages cause several log aggregators to choke (e.g. I have seen problems with this myself in syslog and fluentd), so we now try a bit harder to avoid them if possible.

Changelog

As far as I can tell, you compile the changelog as part of the release process, so I did not touch it in the PR. Here's a suggested wording for the respective changelog entries if this gets merged:

BREAKING CHANGES:

* The error types for specific response codes (`ErrDefault400`, `ErrDefault401`, etc.) have been removed. All unexpected response codes will now return `ErrUnexpectedResponseCode` instead. For quickly checking whether a request resulted in a specific response code, use the new `ResponseCodeIs` function:
  ```go
  result, err := SomeRequest().Extract()
  // before
  if _, ok := err.(gophercloud.ErrDefault404); ok {
    handleNotFound()
  }
  // after
  if gophercloud.ResponseCodeIs(err, http.StatusNotFound) {
    handleNotFound()
  }
  ```
* The error messages returned by ErrUnexpectedResponseCode now include less newlines than before. If you match on error messages using regexes, please double-check your regexes.