Fixes#8983
This patch adds a basic test showing that, when reaching a union type with 30 elements
or more, Psalm used to fail with an error, because the large union type got simplified
into a more general type as part of performance optimizations done in `TypeCombiner::combine()`.
This means that a type like `array<1|2|3|(etcetera...)|100, mixed>` was internally
simplified to `array<int, mixed>`, after reaching 30 elements or more, which in turn
led to problems and confusing errors when large union types are in play.
Such union types are relatively common in lookup-table-alike value objects.
By removing the hardcoded call-time limit of `30` types to be combined, we hereby
rely on the default `TypeCombiner::combine()` limit of `500` items, which is more
healthy.
This may come with some performance implications, but it is worth trying out, for
now.
Further parameters passed to `TypeCombiner::combine()` that were already matching
parameter default values were also omitted from the call-sites.
Getting one interesting failure caused by the `lowercase-string` refinement done before:
```
There was 1 error:
1) Psalm\Tests\AssertAnnotationTest::testValidCode with data set "assertDifferentTypeOfArray" ('<?php\n /*...ts[1];')
Psalm\Exception\CodeException: DocblockTypeContradiction - src/somefile.php:21:21 - Cannot resolve types for $parts - docblock-defined type list{0: lowercase-string, 1?: lowercase-string} does not contain list{string, string}
```
Happens on this bit:
```php
'assertDifferentTypeOfArray' => [
'code' => '<?php
/**
* @psalm-assert list{string, string} $value
* @param mixed $value
*/
function isStringTuple($value): void {
if (!is_array($value)
|| !isset($value[0])
|| !isset($value[1])
|| !is_string($value[0])
|| !is_string($value[1])
) {
throw new \Exception("bad");
}
}
$s = "";
$parts = explode(":", $s, 2);
isStringTuple($parts);
echo $parts[0];
echo $parts[1];',
],
```
If I change this to:
```
@psalm-assert list{lowercase-string, lowercase-string} $value
```
Then everything works: I'm wondering if this error has to do with array intersections, and whether suppressing it suffices.
For now, changing the input string, so it is not a `lowercase-string`, is sufficient.
Note how the signature became `array{0: string, 1?: string, 2?: string, array<int, string>}`,
which may be a side-effect of unions between a defined hashmap structure with array
keys, and `list<string>`.
