Poor `contains` performance

__Steps to reproduce:__
List the minimal actions needed to reproduce the behavior.

1. Push metric data to a bucket
2. Run query in data explorer
```
from(bucket: "randommetrics")
|> range(start: 2022-11-24T05:21:27.284Z, stop: 2022-11-24T11:21:27.284Z)
|> filter(fn: (r) => r._measurement == "metdocker.docker")
|> filter(fn: (r) => r._field == "cpu_used")
|> aggregateWindow(every: 2m0s, fn: mean, createEmpty: false)
|> yield(name: "mean")
```
3. Run same query but using `contains`
```
from(bucket: "randommetrics")
|> range(start: 2022-11-24T05:21:27.284Z, stop: 2022-11-24T11:21:27.284Z)
|> filter(fn: (r) => r._measurement == "metdocker.docker")
|> filter(fn: (r) => contains(value: r._field, set: ["cpu_used"]))
|> aggregateWindow(every: 2m0s, fn: mean, createEmpty: false)
|> yield(name: "mean")
```

__Expected behavior:__

Query times to be similar.

__Actual behavior:__

The query 2 (using equals) takes 0.3s while query 3 (using contains) takes 5.5s
Both yield the same results as I would expect

__Environment info:__

* System info: `Linux 5.10.0-19-amd64 x86_64`
* InfluxDB version: `InfluxDB v2.5.1 (git: 5b6fdbf05d) build_date: 2022-11-02T18:06:28Z`

Start by reproducing the two supplied Flux queries against the stated InfluxDB version and compare their timings. Trace the implementation of the `contains` filter and identify the cause of the slowdown; done means equivalent queries have comparable performance without changing their results.

Written by the indexing model from the issue text.