Adding service address and auth info

[LorenzHW]

I think there are some things that will need to be added (service address, auth info)

@timburks you mentioned here that we should add additional information to the generated output.

Service address:
An example input file might look like this:
input.yaml: (OpenAPI spec)

server:
  - url: https://development.gigantic-server.com/v1
    description: Development server
  - url: https://staging.gigantic-server.com/v1
    description: Staging server
  - url: https://api.gigantic-server.com/v1
    description: Production server

An example output file generated by gnostic-grpc might look like this:
output.proto: (Proto Buf file)

service SomeService {
    // Use the first one if multiple addresses are given
    option (google.api.default_host) = "development.gigantic-server.com/v1";
    // Other code...
}

We can use the default_host service option for that.

Auth info:
Essentially, we want the information of a security scheme object reflected inside the generated proto file.
How should this object be represented inside the generated output file?

As far as I understand, for Google Cloud, one could define a service configuration where additional information (i.e.: authentication) can be provided. This config maps to the service.proto where also the mentioned auth.proto is defined.

We see that for HTTP rules it does not matter whether we define them inside the service config or inside the proto file, however this does not seem to be possible for other configurations.

@timburks and @noahdietz additional input would be helpful.

[noahdietz]

We can use the default_host service option for that.

Yeah, I think that's a good idea - strip the scheme, any path segments included, and include just the host name. Since there can be multiple server objects and we have no way of automatically picking "the right one", we'd probably want to set up a "sane default" like "the first server object is used" (which produces the generated proto you shared). We could have a plugin parameter to override this with a raw value. Also, since there can be variables anywhere in the value, we will need to resolve those with the defaults...

As far as auth...I'm not sure how to handle this. The Service config is not for client consumption, but rather the surrounding API management systems. The proto google.api.http options are only for grpc-HTTP transcoding. I'm not sure that generating a Service config is the right decision...or if supporting this auth information is all that important. If we think about the core feature here its translating OpenAPI to Protobuf, so that we can consume the description via protobuf/gRPC tooling. Auth doesn't factor into the API surface (nor does the default_host really).

[timburks]

This is an interesting long-term goal. As @noahdietz noted, gRPC HTTP/JSON transcoding doesn't include auth information, but it's true that service.proto supports at least some of the schemes that can be specified. This seems pretty strongly associated with API management systems and the OpenAPI spec is probably the only thing they have in common. So maybe it's best to leave this information in the OpenAPI spec. (Ideally, if it's possible for gnostic-grpc to generate the right protos, gRPC HTTP/JSON transcoding would produce an API that matches the original OpenAPI spec, so that spec would still be valid)