Wrong documentation generated for SearchFilter with date properties and exact mode

[idsplus-carlos]

API Platform version(s) affected: 2.5.3

Description
When using SearchFilter on date properties and exact mode, the generated documentation is incorrect. It used to generated a pair of properties, one simple string filter (ie: date_prop: string) and one string array filter (ie: date_prop[]: string[]). Now both are simple strings, even when the second one is named date_prop[].

How to reproduce

1. Add SearchFilter to a class with a DateTime property
2. Add that property to the SearchFilter's properties, with "exact" mode

Possible Solution
The problems lies in DocumentationNormalizer. When it detects a type that's not in Type::$builtinTypes it defaults to $type = ['string'], irregardless of it being a collection or not. Simple solution would be to return another default when encountering a collection, for example replacing:
$type = \in_array($data['type'], Type::$builtinTypes, true) ? $this->jsonSchemaTypeFactory->getType(new Type($data['type'], false, null, $data['is_collection'] ?? false)) : ['type' => 'string'];
with
$type = \in_array($data['type'], Type::$builtinTypes, true) ? $this->jsonSchemaTypeFactory->getType(new Type($data['type'], false, null, $data['is_collection'] ?? false)) : $this->jsonSchemaTypeFactory->getType(new Type('string', false, null, $data['is_collection'] ?? false));

Additional Context

[teohhanhui]

Do not use the SearchFilter with date/time types. It's not designed for that.

If it worked for you, you were just lucky. 🙈

[idsplus-carlos]

I think the bug label still applies though because the default behaviour in DocumentationNormalizer is not correct. It implies that anything not in Type::$builtinTypes is a string, ignoring the collection part, and at the very least should be string[].
In any case, if that's truly unsupported behaviour, it should just throw an exception, not make a soft fail pass on it.

Anyhow, the documentation makes no mention at all about supported use cases for search filter, nor it being designed for strings and/or numbers only. For what types is it designed, then? One could guess strings only going by the name, but then what's exactly doing when you search for a number then?
What's more, if you apply SearchFilter to an Entity (ie, for all properties on a resource), it will happily add exact filters for DateTime properties, and that's definitely a documented use case.

On a more practical side of things, having exact filter around is really useful, because no other built-in filter allows you to filter exactly for one value, or a collection of values.
DateFilter for example only allows you to filter by date ranges. Sure, i could search for an exact date by playing around with before and after, but it's much cumbersome and would only allow for one exact date, not searching for 3 exact dates for example.

[teohhanhui]

You should use NumericFilter / RangeFilter for numbers.

[teohhanhui]

And you're right. It seems SearchFilter is supposed to support many different types. Even though I'm not sure that's a good idea, but that's how it's been for historical reasons...

[soyuka]

To me SearchFilter uses LIKE in sql. Date lookup is much more complicated and is definitely not an officialy supported use case for the SearchFilter. Should we add something in the documentation for this? Your proposed change looks correct, may you propose this patch in a pull request?