fix(search_family): Process wrong field types in indexes for the FT.SEARCH and FT.AGGREGATE commands

[BagritsevichStepan]

fixes #3986

[romange]

I will wait for @dranikpg to review , meanwhile some minor comments so I could understand the PR better

[BagritsevichStepan]

@romange I've added more tests. After adding support for nullable values, a more tests will be added. Please take a look at the PR.

[dranikpg]

My two cents:

1. Please write next time what you changed in the PR description, so I can dive into the changes quicker
2. Maybe look into unifying Matches() and Add(), this would simplify code
3. Please check vectors or add a TODO

If we hurry for a release I can approve 🙂

[BagritsevichStepan]

I found several new bugs and fixed them in the latest commit:

1. Bug:

JSON.SET j1 . '{"data":1}'
JSON.SET j2 . '{"data":"1"}'
FT.CREATE i1 ON JSON SCHEMA $.data AS data NUMERIC
FT.CREATE i2 ON JSON SCHEMA $.data AS data TEXT

FT.SEARCH i1 "*" and FT.SEARCH i2 "*" both return j1 and j2. However, it should return j1 for i1 and j2 for i2. This happens because we are parsing string and numeric fields in the same way in the DocumentAccessor.

2. Bug related to how we parse FtVector in the GetVector function in DocumentAccessor.
3. Bug was crash during JsonAccessor::GetVector when the field type is not an array

I’ve also added more tests

[BagritsevichStepan]

Found and fixed another bug:

We should support queries like this:

JSON.SET j1 . '{"data":["first value", "second_value"]}'
FT.CREATE index ON JSON SCHEMA $.data AS data TEXT

FT.SEARCH index "*" should return j1

[dranikpg]

Good job fixing bugs around vector parsing, it wasn't safe before.

Still, once we merge this for 1.25, I'd suggest to unite IsValidFieldType and Add, because we have safe/unsafe parsing functions, optionals that are dereferenced "by implicit contract" and double effort indexing documents (we parse it two times)