Add a test of metadata, status code, and details

[nathanielmanistaatgoogle]

Fixes issue 4545.

Please pay particular attention to the way .decode('utf-8') is used on strings; please feel free to say "oh no I see what you're going for but the better way is <...>".

[thunderboltsid]

I don't see a problem with the way decode is used. The other option is using python struct library and do struct.unpack(...) but this is definitely not necessary here.

[kpayson64]

b'/'.join(b'', _SERVICE , _UNARY_UNARY) seems to accomplish this a bit more eloquently.

[nathanielmanistaatgoogle]

Agreed; done.

[nathanielmanistaatgoogle]

(The content of this pull request has now also undergone a with_call=True→multi_callable.with_call conversion.)

[kpayson64]

Lgtm

[jcanizales]

To clarify, because I've become a bit unfamiliar with the Python API: where in the tests are error details being set by the server, and where are they read by the client? (Maybe we can add a comment?)

[nathanielmanistaatgoogle]

@jcanizales: the code is set in a call to ServicerContext.set_code (such as this one), the details are set in a call to ServicerContext.set_details (such as this one), the code is read in a call to Call.code (such as this one), and the details are read in a call to Call.details (such as this one).

[jcanizales]

Oh! You're talking "details" as in "error message". The original issue was about extra error details that would be transmitted as protos, serialized in the server and parsed by the client, for programmatic handling. Sorry that that wasn't clear.