profiler: use functional options instead of config object

[derekperkins]

I'm not a huge fan of config objects, and functional options are used in many other places in these packages. It'd be easier to maintain backwards compatibility. There are already functional options for ClientOption, which could either be applied as a part of a ProfilerOption or sent through on a start func.

func NewProfiler(opts ...ProfilerOption) (*Profiler, error) {
	...
}

func (p *Profiler) Start(opts ...ClientOption) error {
	...
}

[jba]

It's partly because of ClientOption that we decided to use a config struct here. We couldn't come up with a nice way for particular clients to add their own ClientOptions.

I've come to dislike options for other reasons: they clutter the surface, they are hard to recognize as options (godoc doesn't group them together), and they have package-level names so the names have to be long enough to be unambiguous. ClientOption doesn't have these problems, because it lives in its own package, but client-specific options would.

The only real downside to a config object is that you may have to write an empty one, which is unattractive, but not otherwise harmful.

I don't think a config object hinders backwards compatibility. Adding a field to a struct is backwards-compatible.

[derekperkins]

👍