feat: Add sparse vectors benchmark support for Qdrant

[KShivendu]

This PR does the following:

• Introduce a sparse dataset reader
• Refactor base client and dataclasses to support sparse vectors
• Use msmarco-sparse-1M dataset used in https://github.com/qdrant/sparse-vectors-benchmark
• Add sparse vector benchmark support for Qdrant.

TODO:

• Apply same client refactors to engine classes (PR refactor: Update all engines to use Query and Record dataclasses #116)
• Test all the engines locally with sparse and non-sparse datasets.
• Run continuously with CI and cross check everything (Can only be done after merging. Read this)
• Allow running sparse configs with only sparse datasets

[agourlay]

@KShivendu Is there some result files to have a look at already?

[KShivendu]

Looks like the CI benchmarks for sparse vectors aren't actually running for now because we use qdrant/vector-db-benchmark:latest image. This PR needs to be merged to properly test this on CI.

However, I've testing this locally and it worked as expected. So we can merge once we are sure about the refactors introduced in this PR.

[joein]

Query in ann_h5_reader and maybe in some other readers require sparse_vectors to be set + #117

[joein]

why do we need to do it?

[KShivendu]

I thought that's the only way to do it. Using this now:

if point.sparse_vector is None:
    vector = point.vector
else:
    vector = {
        "sparse": SparseVector(
            indices=point.sparse_vector.indices,
            values=point.sparse_vector.values,
        )
    }

Would have been nice if we could keep it similar to search. But qdrant-client doesn't support this. Wdyt?

if point.sparse_vector is None:
    vector = point.vector
else:
    vector = NamedSparseVector(
        name="sparse",
        vector=SparseVector(
            indices=point.sparse_vector.indices,
            values=point.sparse_vector.values,
        ),
    )

[KShivendu]

I prefer not to bring changes, if they are not necessary
However, if you have already checked that it does not break anything and does not affect the performance, then I assume I don't have objections

I haven't tested this but imo lightweight dataclasses shouldn't cause significant perf degradations. It's not even pydantic, so no validations are involved.

Regarding the breaking anything part, I've tested Qdrant sparse and dense datasets locally and they worked. I did the refactor for other engines and also introduced Ruff linter pre-commit hook in this PR.

[generall]

Let's see how it works