Flatten deep BooleanOr chains in resolveType() to avoid O(n^2) scope narrowing

[SanderMuller]

A single || with many instanceof (or comparison) arms is very slow to analyse. On this base a 150-arm chain takes about 48s and a 100-arm chain about 9s.

BooleanOrHandler::resolveType() computes the boolean type of a BooleanOr by taking the type of the left operand and then re-narrowing the whole left chain with filterByFalseyValue() before it looks at the right operand. Because the left operand is itself a BooleanOr, this recurses, and each level re-narrows the entire chain below it. For n arms that is O(n^2) narrowing work stacked on top of the recursion, which is what makes it blow up.

(The issue attributes the cost to scope merging in processExpr(). I instrumented that path and mergeWith() is negligible here; the dominant cost is the recursive re-narrowing in resolveType() described above.)

This flattens the chain in resolveType() and iterates the arms once, threading the falsey scope arm by arm: the chain is true if any arm is true given the previous arms are false, false if every arm is false, and bool otherwise. It only takes this path past the existing BOOLEAN_EXPRESSION_MAX_PROCESS_DEPTH, and mirrors the specifyTypesForFlattenedBooleanOr() that already exists on the type-specifying side.

Measured on this base (opcache off, single process):

arms	before	after
100	8.6s	1.5s
150	47.7s	3.4s

Analysis output is byte-identical before and after on phpstan-src's own src/ (same errors, same counts), so this is a performance-only change. A regression test in nsrt/bug-14477.php covers both the boolean type of the chain and the truthy-branch narrowing.

Closes phpstan/phpstan#14477

[ondrejmirtes]

Benchmarks belong to tests/bench/data, I'll regenerate the baseline once this is merged.

[staabm]

Needs a bench test which reproduces slowness without the actual fix

[SanderMuller]

Added tests/bench/data/or-chain-resolve-type-blowup.php, alongside the existing and-chain-truthy-blowup.php and or-chain-falsey-blowup.php. It is a 100-arm instanceof || chain, which is what makes the per-level narrowing expensive enough to expose the resolveType() O(N^2) at the default BOOLEAN_EXPRESSION_MAX_PROCESS_DEPTH (no raised cap needed, unlike the falsey one).

Locally (single process, opcache off) it goes from about 8.5s without the fix to about 1.3s with it, and it reports no errors so the bench only measures analysis time. I left the baseline for you to regenerate on merge.

[ondrejmirtes]

Thank you!