GODRIVER-2859 Add search index management helpers

[qingyang-hu]

GODRIVER-2859
GODRIVER-2875

Summary

Add search index management helpers.

Background & Motivation

https://github.com/mongodb/specifications/blob/master/source/index-management/index-management.rst#search-indexes
https://github.com/mongodb/specifications/blob/master/source/index-management/tests/README.rst#search-index-management-helpers

[matthewdale]

This should append to the test.suite file so that the test output can be parsed by Evergreen.

Suggested change

	go test ./mongo/integration -run TestSearchIndexProse -v -timeout $(TEST_TIMEOUT)s
	go test ./mongo/integration -run TestSearchIndexProse -v -timeout $(TEST_TIMEOUT)s >> test.suite

[matthewdale]

I'm a little worried about the usability problems that using string pointers introduces, especially because there is no Go syntax for declaring pointers to literal strings. We use that pattern in the WriteConcern type, but the negative usability impact seems greater than anticipated.

If we need to be able to distinguish between empty string and no value provided, would adding name to ListSearchIndexesOptions be a better option?

E.g. using string pointer:

coll.SearchIndexes().List(ctx, nil)

name := "myIndex"
coll.SearchIndexes().List(ctx, &name)

E.g. using ListSearchIndexOptions:

coll.SearchIndexes().List(ctx)

coll.SearchIndexes().List(ctx, options.ListSearchIndexes().Name("myIndex"))

Another consideration is that the $listSearchIndexes aggregation pipeline supports both "id" and "name filters. If we ever need to support the "id" filter in the future, we would need to add it somewhere. We could accept a filter interface{} parameter, similar to ListCollections. However, that would be less usable for a simple string filter because users would have to figure out how to assemble the filter document themselves. Also, the filter document format for ListCollections is very different than the filter document format for $listSearchIndexes.

E.g. using filter:

coll.SearchIndexes().List(ctx, nil)
coll.SearchIndexes().List(ctx, bson.D{{"name", "myIndex"}})

I don't think any of those are the obvious best choice. Which do you prefer?

[matthewdale]

Optional: Consider inverting the if condition and returning early so you can un-indent the remaining code.

E.g.

func (r Raw) Elements() ([]RawElement, error) {
	doc := bsoncore.Document(r)
	if len(doc) == 0 {
		return nil, nil
	}

	elems, err := doc.Elements()
	if err != nil {
		return nil, err
	}

	relems := make([]RawElement, 0, len(elems))
	for _, elem := range elems {
		relems = append(relems, RawElement(elem))
	}

	return relems, nil
}

[matthewdale]

Looks good 👍

[matthewdale]

Optional: Long lines can be difficult to read. Consider wrapping them.

E.g.

func (siv SearchIndexView) List(
	ctx context.Context,
	searchIdxOpts *options.SearchIndexesOptions,
	opts ...*options.ListSearchIndexesOptions,
) (*Cursor, error) {

That suggestion applies to all long function signatures in this PR.