[configrpc] Consider adding option wrapper on ToServer and ToClientConn

[mx-psi]

Instead of passing grpc.ServerOptions to each, we could pass new ToServerOptions or ToClientOptions and require wrapping grpc.ServerOptions into these, to make the interface more flexible and allow for other kinds of options in the future.

[TylerHelmuth]

@mx-psi can you elaborate a little more on what you'd like to see?

For our ServerConfig.ToServer for example, we end up calling grpc.NewServer and passing it a []grpc.ServerOption. But grpc.ServerOption is an interface that we can't implement in configgrpc. We need to end up with grpc.ServerOption to call grpc.NewServer, so would we be creating a wrapper of every Option function in grpc? Something like:

type ToServerOption func() grpc.ServerOption

func MaxConcurrentStreams(n uint32) ToServerOption {
	return func() grpc.ServerOption {
		return grpc.MaxConcurrentStreams(n)
	}
}

Since grpc.ServerOption isn't extendable I don't see how we make our own package more extendable.

I believe grpc.DialOption has the same limitation.

[TylerHelmuth]

Are you thinking we add something like confighttp has and then add wrappers for each grpc.ServerOption?

[mx-psi]

Are you thinking we add something like confighttp has and then add wrappers for each grpc.ServerOption?

Yes, that's what I was thinking:

type ToServerOption ... // opaque type here, likely a sealed interface

func WithgRPCServerOption(opt grpc.ServerOption) ToServerOption {
	return // wrap the option here into a `ToServerOption`
}

// Maybe add other options in the future that are not grpc.ServerOption

[TylerHelmuth]

@mx-psi i am worried that this solution will mean we have to remember to update our options whenever a new grpc option comes out. If we are ever behind it will mean a grpc option exists that isn't usable with configgrpc. Is that ok?

[mx-psi]

@TylerHelmuth We would just have just a single wrapper WithGRPCServerOption(opt grpc.ServerOption) ToServerOption, so there's no need to keep up to date, right?

[TylerHelmuth]

@mx-psi if we can get away with just the 1 generic wrapper that's great. Based on my brief experimentation the lack of exported fields in grpc and the need to end up with []grpc.ServerOption before calling grpc.NewServer will pose a challenge I think, but worth looking into more.

[TylerHelmuth]

@mx-psi we could do something like this:

// toServerOptions has options that change the behavior of the gRPC server
// returned by ServerConfig.ToServer().
type toServerOptions struct {
	grpcServerOptions []grpc.ServerOption
}

// ToServerOption is an option to change the behavior of the gRPC server
// returned by ServerConfig.ToServer().
type ToServerOption func(opts *toServerOptions)

func WithgRPCServerOption(opt grpc.ServerOption) ToServerOption {
	return func(opts *toServerOptions) {
		opts.grpcServerOptions = append(opts.grpcServerOptions, opt)
	}
}

// ToServer returns a grpc.Server for the configuration
func (gss *ServerConfig) ToServer(_ context.Context, host component.Host, settings component.TelemetrySettings, extraOpts ...ToServerOption) (*grpc.Server, error) {
        // this is an existing function that makes a bunch of grpc.ServerOptions based on the host/settings.
	opts, err := gss.toServerOption(host, settings)
	if err != nil {
		return nil, err
	}
	tso := toServerOptions{}
	for _, otp := range extraOpts {
		otp(&tso)
	}
	opts = append(opts, tso.grpcServerOptions...)
	return grpc.NewServer(opts...), nil
}

Is this what you had in mind?

[TylerHelmuth]

This pattern conflicts with #9479 tho, but it could be made to fit the interface pattern instead.

[mx-psi]

@TylerHelmuth Yeah, that's what I had in mind! Sorry that I wasn't very clear in the previous messages, my bad 😅

[atoulme]

@legendary-acp go for it

[jade-guiton-dd]

I'll take this one.

[mx-psi]

This still needs removing and renaming the deprecated APIs, reopening