Include operation_id in error strings

[cben]

Here's an example of a pretty idiomatic SDK usage:
https://github.com/openshift/osde2e/blob/143f353ea48119e9dc3e65868cc2466e738c9943/pkg/osd/cluster.go#L74-L103
(where u.clusters() returns u.conn.ClustersMgmt().V1().Clusters())

This code eventually logged the following error:

failed waiting for cluster ready: Encountered error waiting for cluster: couldn't get cluster '1b9b8un2n10cbv8l5oaq2ek0m5fdf07p': couldn't retrieve cluster '1b9b8un2n10cbv8l5oaq2ek0m5fdf07p': CLUSTERS-MGMT-500

where most of the error is from the calling osde2e code, apparently CLUSTERS-MGMT-500 is the only part that came from the SDK.

In this case, I failed to find matching clusters-service logs to this 500 (interal hive-integration env).
Almost always 500 errors include an "operation_id": "...." field, and these make later searching much easier.
I think it would be good if the SDK included such id, when available, in the error string it returns.

I guess the reason we didn't do this already is our internal code using the SDK tends to log the full response body on errors. In osde2e code, the immediate function returns the body too:

return resp.Body(), resp.Error()

but then the calling function ignores the body because err != nil. Which I think is likely to happen in real-world usage, frequently only the error string propogates out...

@jhernand what do you think? cc @meowfaceman @ethernetdan from osde2e

[mdwn]

Just reviving this a bit -- we've seen this a few times recently. I think this is a good idea. cc @jeefy (@ethernetdan is no longer on osde2e).

[jhernand]

This is fixed in release 0.1.89. For a JSON error document like this:

{
  "kind": "Error",
  "id": "401",
  "href": "/api/clusters_mgmt/v1/errors/401",
  "code": "CLUSTERS-MGMT-401",
  "reason": "My reason",
  "operation_id": "456"
}

The Error and String methos of the error type of the SDK will no return someting like this:

identifier is '401', code is 'CLUSTERS-MGMT-401' and
operation identifier is '456': My reason