Add monoids for options about connect-go

[bufdev]

What is the purpose of this? I don't immediately get it

[akshayjshah]

Imagine your organization (like Buf!) has a standard collection of options that you'd like every handler, client, or both to use. Without this, you end up with a fairly unpleasant set of APIs: StandardClientOptions() []connect.ClientOption, etc., and users are constantly appending to slices and splatting them again.

client, err := NewFooClient(...,
  append(someorg.StandardClientOptions(),
    SomeSpecificOption(),
    SomeOtherOneOffOption(),
  )...,
)

With these functions, life's a bit nicer. someorg.StandardClientOptions can bundle a bunch of options into a single connect.ClientOption, and the user code ends up like this:

client, err := NewFooClient(...,
  someorg.StandardClientOptions(),
  someorg.UnusualOption(),
  MyOneOffOption(),
)

Ultimately, it's convenient for users to be able to make a single option have multiple effects. More or less, this is the same reason your proposal to build a multi-plugin for protoc/buf is nicer than forcing every tool to take a list of plugins to generate into the same directory.

[akshayjshah]

Examples from other packages I've worked on:

• https://pkg.go.dev/go.uber.org/[email protected]/zapcore#NewTee
• https://pkg.go.dev/go.uber.org/fx#Options

Both of those options ended up pretty widely used, and the fx one in particular was a cornerstone of the whole ecosystem.

[bufdev]

I'm not sure this will be as used in the connect world and it just adds to the number of types, but you feel strongly about it and it's fine with me. I might say that WithOptions confuses me a bit as opposed to something signaling this is a union of options like (and not suggesting this directly) but MultiOption