Fix GH-21831: Disallow SplObjectStorage mutation during getHash()

[prateekbhujel]

FixesGH-21831.

getHash() runs while SplObjectStorage is looking up an object. Letting it mutate a storage from there is unsafe, because the caller may still be iterating the table that just changed underneath it.

This makes that fail immediately with an Error instead of trying to handle it one caller at a time.

The existing concurrent deletion tests now cover the new rule, and GH-21831 has a direct regression test. This targets master, so the behavior change is also noted in UPGRADING.

Tested with:

sapi/cli/php run-tests.php -q ext/spl/tests/SplObjectStorage

[Girgias]

I'm not sure I like this approach, but not sure how what I would want the behaviour to be is achievable.

Ideally one shouldn't be able to mess with the state from the getHash() method, as it's meant to be somewhat of a pure function.

[prateekbhujel]

Yeah, I agree with that.

getHash() really should behave like a pure lookup, so being able to mutate either storage from there is pretty awkward. I kept this one narrow and just made removeAllExcept() resilient to that re-entrancy, rather than trying to change what getHash() is allowed to do as part of a bug fix.

[Girgias]

I think it would be cleaner to just change what getHash() is allowed to do, considering you are already targeting master and this seems very artificial so not sure it's worth backporting

[prateekbhujel]

@Girgias pushed that version now. I changed it so mutation during getHash() throws, instead of trying to make only removeAllExcept() deal with this case. The existing concurrent-deletion tests are now updated around that rule, and I added the GH-21831 regression test too. Also added the UPGRADING note since this is master-only and changes behavior.

[Girgias]

Thank you for the new approach, I think this is better suited.