Create a pattern for reporting fine-grained error details in a machine-readable way

[ahmedtd]

Currently, we are testing the error message strings emitted from ate-api-server in functional_test.go. This is pretty fraught, since those messages aren't necessarily going to be stable as code is refactored.

Instead, we should use the Status.Details field with an ate-specific details proto. We can define a fine-grained code for each logical error, in case clients need to distinguish situations beyond just the canonical code.

For example,

• If we can't find a free worker, we might return a status error where code=RESOURCE_EXHAUSTED, and details has an ateapipb.ErrorDetails proto with fine_grained_code=NO_FREE_WORKERS

[juli4n]

A couple of thoughts:

• ATE's clients should not use error message strings to drive decisions. I don't think we are doing this in any place today.
• I agree that we might need error codes that are more fined grained that gRPC canonical codes. We should follow https://google.aip.dev/193#statusdetails.
• Whether we want functional hermetic tests to assert on the error message or not. In my experience, there is value in doing it, at least if you care about reporting good error messages, and it really depends on the programming model we have to wrap / annotate / map Go errors to gRPC errors.