$in and $or too slow for large database (doesn´t use index)

My database has 4.7GB of data (3191269 docs)
Attribute _id has implicit index.
```
{
"type": "special",
"def": {
"fields": [
{
"_id": "asc"
}
]
}
}
```

This selector works well:

```
{
"selector": {
"_id": {
"$eq": "CustomerElastic_00001280-7a18-466b-9e9c-da5a2d903bda"
}
}
}
```

This selector is pending and never finished (the same when I use $or):

```
{
"selector": {
"_id": {
"$in": ["CustomerElastic_00000a29-329f-477f-8d4a-8244a9c738aa", "CustomerElastic_00001280-7a18-466b-9e9c-da5a2d903bda"]
}
}
}
```

Why?

[NOTE]: # ( Describe the problem you're encountering. )
[TIP]: # ( Do NOT give us access or passwords to your actual CouchDB! )

## Steps to Reproduce

Use fauxton and mango query.

## Expected Behaviour

It should work the same as $eq

## Your Environment

{"couchdb":"Welcome","version":"3.3.2","git_sha":"11a234070","uuid":"ff2fae1b3089d86fd741e84a6e532eda","features":["access-ready","partitioned","pluggable-storage-engines","reshard","scheduler"],"vendor":{"name":"The Apache Software Foundation"}}

* Browser name and version: Chrome latest version
* Operating system and version: Windows 11

Reproduce the selectors in Fauxton against a CouchDB 3.3.2 database with the described _id index and compare the behavior of $eq, $in, and $or. Trace Mango query planning and index selection to determine why the multi-value selectors do not complete; done means they use the available index and return the expected documents, with regression coverage.

Written by the indexing model from the issue text.