feat: add RPCs returning unknown enum values over REST

[vchudnov-g]

This adds two new RPCs, Compliance.RepeatWithUnknown{,Optional}Enum() which, when called over REST, populate enum fields in the JSON responses with string values that do not correspond to enum values in the protobuf definition. This should be used by generators to ensure that when the server returns an unknown enum value as part of a REST response, the GAPICs handle it gracefully.

Below are command-line examples of calling these RPCs. Note that LIFE_KINGDOM_NEW is the unknown enum value not present in the proto.

Non-optional enum fields:

❯ curl -i -X POST http://localhost:7469/v1beta1/repeat:invalidenum -d'{}' -H "Content-Type: application/json" -H "X-Goog-Api-Client: rest/0.0.0 gapic/0.0.0"                                                                    
HTTP/1.1 200 OK
Date: Wed, 25 Aug 2021 17:34:20 GMT
Content-Length: 514
Content-Type: text/plain; charset=utf-8

{
  "request": {
    "name": "",
    "info": {
      "fString": "",
      "fInt32": 0,
      "fSint32": 0,
      "fSfixed32": 0,
      "fUint32": 0,
      "fFixed32": 0,
      "fInt64": "0",
      "fSint64": "0",
      "fSfixed64": "0",
      "fUint64": "0",
      "fFixed64": "0",
      "fDouble": 0,
      "fFloat": 0,
      "fBool": false,
      "fBytes": "",
      "fKingdom": "LIFE_KINGDOM_NEW",
      "fChild": null
    },
    "serverVerify": false,
    "fInt32": 0,
    "fInt64": "0",
    "fDouble": 0
  }
}

Optional enum fields:

❯ curl -i -X POST http://localhost:7469/v1beta1/repeat:invalidoptionalenum -d'{}' -H "Content-Type: application/json" -H "X-Goog-Api-Client: rest/0.0.0 gapic/0.0.0"
HTTP/1.1 200 OK
Date: Wed, 25 Aug 2021 17:35:22 GMT
Content-Length: 560
Content-Type: text/plain; charset=utf-8

{
  "request": {
    "name": "",
    "info": {
      "fString": "",
      "fInt32": 0,
      "fSint32": 0,
      "fSfixed32": 0,
      "fUint32": 0,
      "fFixed32": 0,
      "fInt64": "0",
      "fSint64": "0",
      "fSfixed64": "0",
      "fUint64": "0",
      "fFixed64": "0",
      "fDouble": 0,
      "fFloat": 0,
      "fBool": false,
      "fBytes": "",
      "fKingdom": "LIFE_KINGDOM_UNSPECIFIED",
      "fChild": null,
      "pKingdom": "LIFE_KINGDOM_NEW"
    },
    "serverVerify": false,
    "fInt32": 0,
    "fInt64": "0",
    "fDouble": 0
  }
}

[noahdietz]

Could these be one request with two fields and maybe a field to toggle behavior? For example, we have the Echo RPC which could return either an EchoResponse or an error status depending on what was sent in the request oneof. Might simplify the implementation a bit?

[vchudnov-g]

I've been thinking about this (and sidetracked by other issues, sorry). We could keep just the previously existing RPCs and add a top-level field to RepeatRequest to generate the unknown enum. In fact, I would change RepeatRequest.server_verify to be an enum like server_behavior that could be verify, or generate_unknown_enum, or something else in the future.

Not too concerned about that being a breaking change because (a) most generators are not yet using the compliance suite, and (b) the compliance suite is meant to be parsed form this repo and then used to issue requests, without the client code modifying the request.

WDYT?

[noahdietz]

Yeah that sounds great to me. Thanks for considering this.