feat(NODE-5314): add search index helpers

[baileympearson]

Description

POC for mongodb/specifications#1423.

What is changing?

• 5 new operations are added to the unified test runner
• new collection helpers are added to enable search index management

Is there new documentation needed for these changes?

No.

Double check the following

• Ran npm run check:lint script
• Self-review completed using the steps outlined here
• PR title follows the correct format: type(NODE-xxxx)[!]: description
  • Example: feat(NODE-1234)!: rewriting everything in coffeescript
• Changes are covered by tests
• New TODOs have a related JIRA ticket

[baileympearson]

This change is not necessary but without it, the operations added in this PR must either assert on the namespace's collection string being truthy or provide a default value, but in all cases the namespace has a collection defined (they're all operations defined on the collection).

[nbbeeken]

I have another thread where I mention we do not need this if we pass through the namespace instead of the collection instance, so let's address that first. But following up here let's unit test withCollection & this class

[nbbeeken]

Since the return value is the same for all these methods so we should just have the union type argument and optional options

[baileympearson]

That's not quite the same. Collapsing them into a single overload implies that listSearchIndexes(AggregateOptions, AggregateOptions) is a valid signature. Overloading the method clarifies which combinations of arguments are valid.

[nbbeeken]

Calling the method with listSearchIndexes(options, options) will work though, so I don't know if there's much risk to that implication. I think that the UX is reasonably clear without it

But if we do keep the overload the one after the first one doesn't have documentation, overloads each need their own tsdoc block

[baileympearson]

Maybe this is my particular workflow, but I often peruse the overloads for methods by scrolling through the modal that pops up in vscode. I think it's beneficial to provide clear intended usages. I added an additional tsdoc comment for the new overload.

Also, listSearchIndexes(options, options) won't work because the actual pipeline stage sent will be:

{ $listSearchIndexes: { name: <aggregation options > } }

[nbbeeken]

Yea that's fair, I think the union of types is equally clear, the possible inputs are listed in one popup, no scrolling needed.

Also, listSearchIndexes(options, options) won't work because the actual pipeline stage sent will be: { $listSearchIndexes: { name: <aggregation options > } }

From the option handling:

   : typeof indexNameOrOptions === 'object'
        ? null

This case should set the name to null and then the pipeline will be constructed correctly in the cursor since we test for name == null.

[nbbeeken]

I have another thread where I mention we do not need this if we pass through the namespace instead of the collection instance, so let's address that first. But following up here let's unit test withCollection & this class

[dariakp]

Just some clarifying questions

[lerouxb]

Should these be @internal? Once released we're going to have to use them from mongosh, right?

[baileympearson]

We don't want to release an untested API as public yet, so they're internal for now until we can manually e2e test them.

@internal only strips things out of the Typescript definitions, everything will still be accessible. It might be slightly more inconvenient to work with in mongosh, but it should still work.

Is that alright with you?

[lerouxb]

That's fine, I guess. I forked this branch so I can work with it locally in the meantime anyway.