Context

Problems:

• The "options" name conflicts with a common variable name, meaning people frequently have to alias it when importing. Almost all uses of the Go Driver require importing the "options" package to configure a Client, so that name is always taken.
  • We actually use other "options" packages in the experimental APIs, meaning we have to alias it internally because of name conflicts.
• All options structs and struct fields have to be exported so they can be accessed by other packages. Combined with the options builders, that means the API has at least twice as many symbols as there are options (one for the struct field, one for the builder method).
  • Maintaining both options structs and builders for the same APIs also makes naming awkward. The convenience function for creating an option type for a driver operation (e.g. options.FindOne() conflicts with the simplest struct name, requiring us to add redundant words to the struct name (e.g. options.FindOneOptions).

We should move all "options" packages types and functions to the "mongo" package and come up with a pattern that allows us to significantly reduce the number of exported symbols.

Definition of done

What must be done to consider the task complete?

Pitfalls

• It's possible the resulting API will be more confusing and/or more difficult to use than the current API.
• It's possible there won't be a way to reduce the number of exported symbols, resulting in a bloated "mongo" package.
• Other experimental and internal packages import the "options" package currently. There may be significant work and struct duplication required to move the "options" package into the "mongo" package.