[public-api] Remove google.Status from proto responses

[easyCZ]

Description

• Removes google.Status from proto responses. This is redundant as the gRPC response already has the google.Status in it. It's either in the form of an Error, or an OK which doesn't need the status. If we need more detailed status errors, we can use the native error (and status) model https://cloud.google.com/apis/design/errors, with rich and detailed error messages serialized in the Error.details field
• Removes linter which was enforcing this (if we want a linter for something else, we can restore from git)

Related Issue(s)

• Depends on [public-api] Fix codegen #9605
• Part of Deploy a Hello World server as initial Public API  #9229

How to test

• CI runs
• cd components/public-api && ./generate.sh works

Release Notes

NONE

Documentation

NONE

[csweichel]

The intent of shipping google.Status was provide structured errors from day 1. If we remove it, we'll have a harder time adding structured errors back in on a later day.

Not hell-bent on the google.Status implementation, but there's been plenty a discussion on this topic.
Let's catch up on this in the sync call tomorrow.

[easyCZ]

So google.Status represents the Response Status, similar to HTTP Response Codes. It is not intended to communicate the underlying resource status, just the ability to respond to a request. For that, we should define our own (and we already do in the form of WorkspaceStatus and similar).

To put it differently, we wouldn't include

{ statusCode: 404, statusMessage: Not Found }

In a regular HTTP response, but that's what we're doing here with google.Status.

[geropl]

My understanding from the Offsite, after some lengthy discussions, was:

• we all want structured error types
• we have two suggestions on how to implement that. We try out both with small examples, and judge based on how the client code looks like. IIRC the options were:
  • map errors to google.Status
  • use a custom field as initially suggested here (but in a slightly improved way)

My understanding was that for both approaches we do not need the explicity response_status. 🤔

[csweichel]

@easyCZ and I had an offline discussion where we came to the conclusion that:

• google.Status does not serve the purpose we had intended, i.e. it's too generic to provide meaningful structured errors,
• we'll want to keep things simple and go with gRPCs built-in errors for now - we can add structured errors down the road if we need to.

[easyCZ]

/unhold

[easyCZ]

/hold

[easyCZ]

/unhold

[easyCZ]

/werft run

👍 started the job as gitpod-build-mp-public-api-remove-gp-lint.8
(with .werft/ from main)

[geropl]

LGTM (see discussion ☝️ )