Set RetryInfo as part of `trailing_metadata` to properly return it to clients

Before raising this MR, consider whether the following are required, and complete if so:

• Unit tests
• Metrics
• Documentation update(s)

If not required, please explain in brief why not.

Description

!665 (merged) added support for sending RetryInfo status details in certain error responses, but it turns out setting this is more tricky than it should be. As it turns out, using the standard set_code and set_details methods doesn't allow any way to send any detailed metadata to the client. It is possible though, and looking at the recommended way as per https://github.com/grpc/grpc/tree/master/examples/python/errors leads you to think that using the grpcio-status package is how to do it.

Unfortunately it isn't so simple. grpcio-status has a hard dependency on https://github.com/googleapis/api-common-protos, which ships some of these common protos as well as their compiled variants. This causes conflicts with the versions we have generated locally. Add in the fact that this repository doesn't seem to be all that well maintained and using this module doesn't seem like a reasonable thing to do. https://github.com/googleapis/api-common-protos/issues/88

Thankfully, the actual functionality provided by grpcio-status is super bare-bones, and we can just do an equivalent thing in our code. Specifically, have RetriableError also construct a grpc.Status with everything set up and the RetryInfo message set as part of the trailing_metadata. This grpc.Status is suitable for calling context.abort_with_status, which as far as I can tell is the correct way to do this kind of thing.

https://github.com/grpc/proposal/blob/master/L44-python-rich-status.md goes into some of the history of this for anyone who wants to get as deep in the rabbit-hole as I.

Validation

Added to the existing test in test_sql.py to also verify that e.error_status is correct. Putting this in Draft while I do some more manual testing on this.