RUST-1667 Add search index management helpers

[abr-egn]

RUST-1667

Nothing particularly unusual. New commands, new wrappers for them, new unified tests. The only thing of note is that the commands are proxied server-side to a different process, so stuff like write concerns and sessions don't apply.

[isabelatkinson]

It could be nice to return a concrete type in this cursor like we do for the regular list_indexes method -- do the documents returned here match the shape of SearchIndexModel?

[abr-egn]

The spec doesn't actually say, it just gives the return as Document. Looking at other drivers, C++ and Go don't even have support for a type-parameterized cursor; Java provides both a Cursor<Document> and a Cursor<T> but no specific concrete type. Given that, I'd like to leave it at the more general.

[abr-egn]

An update here - the document returned isn't at all in the shape of SearchIndexModel, it's its own thing:

    Document({
        "id": String(
            "6553a4ec949b624697d5d1f8",
        ),
        "name": String(
            "test-search-index",
        ),
        "status": String(
            "PENDING",
        ),
        "queryable": Boolean(
            false,
        ),
        "latestDefinitionVersion": Document({
            "version": Int64(
                0,
            ),
            "createdAt": DateTime(
                2023-11-14 16:48:44.772 +00:00:00,
            ),
        }),
        "latestDefinition": Document({
            "mappings": Document({
                "dynamic": Boolean(
                    false,
                ),
            }),
        }),
        "statusDetail": Array([]),
    }),

[isabelatkinson]

Oh interesting, I was going to say that I would prefer consistency with our existing API but that's not much of a concern if the return types are so different. Sticking with Document SGTM.

[isabelatkinson]

It's a bummer that nested impls aren't allowed, because I think this type would ideally be something like impl Into<Option<impl AsRef<str>>>. With this type definition, passing in the name field of a SearchIndexModel will require model.name.as_deref() as Option<String> don't pass the impl test. An outright String requires s.as_str().

I wonder if it would be more ergonomic to make this type Option<impl AsRef<str>>. That would allow passing model.name directly, but users would need to wrap a non-optional String or &str in Some. I'm not sure which use case is better to optimize for, WDYT?

[abr-egn]

I went down a rabbit hole here - I originally tried having both types be full parameters with where clauses, but that doesn't work either because it requires annotations for the None case. It seemed like providing a default for the inner type would be the way to go, but that's not supported on functions because the semantics are actually less obvious than it seems.

I'd lean towards keeping the Into<Option<..>> for consistency with the rest of the API (including the other parameters of this fn).

[isabelatkinson]

Is this necessary? IIRC these options are propagated from the client when a db/coll is instantiated and then resolved with the resolve_options! macro, so I think they will only get applied if they're explicitly folded into the options provided to a method (which we're not doing in these helpers)

[abr-egn]

It's needed for list_search_indexes, which is implemented as an aggregate call.

[isabelatkinson]

good call on moving these to their own file, operation.rs is huge and could probably use some modularization

[abr-egn]

Filed RUST-1800 for this.

[isabelatkinson]

Oh interesting, I was going to say that I would prefer consistency with our existing API but that's not much of a concern if the return types are so different. Sticking with Document SGTM.