Refactor mb_substitute_character() to use string|int fast ZPP check

[Girgias]

Targeting master and rework of #5348

I'm not sure what the best way was to handle int|string with ZPP so I came up with this horror... Any better idea or should I just use a zval and a switch block again?

[cmb69]

If I'm not mistaken, the sole parameter of mb_substitute_character() is actually string|int|null (the stub doc comment says it would be string|int). Since ZPP is not quite cheap performance wise, it may make sense to have 2 ZPPs (one checking for int and the other for ?string, or some other combination), but 4 ZPPs look over-engineered. However, I'm not sure whether this would be helpful, given the somewhat special argument requirements, and the inherent weak typing of internal functions. It might be best to just stick to the current type switch.

[Girgias]

If I'm not mistaken, the sole parameter of mb_substitute_character() is actually string|int|null (the stub doc comment says it would be string|int). Since ZPP is not quite cheap performance wise, it may make sense to have 2 ZPPs (one checking for int and the other for ?string, or some other combination), but 4 ZPPs look over-engineered. However, I'm not sure whether this would be helpful, given the somewhat special argument requirements, and the inherent weak typing of internal functions. It might be best to just stick to the current type switch.

It's better described as string|!string (meaning string or anything which is not a string) as currently anything that is not a string (well even if it's a string but fails the comparison to one of the preassigned strings) will be silently converted to an integer, this includes null which is converted to 0.

I just thought of a trick to reduce it from 4 to 3 ZPP checks, but I think the way to solve this ludicrous over engineering is to have a Fast ZPP macro which can check if an argument is integer or string, in the same way as we have one for array|string

[Girgias]

Well I decided to use a big switch instead and implement strict_types handling manually, still can't use actual type hints otherwise a ZPP mismatch is emitted.

[Girgias]

This is now based on #5449

[Girgias]

@nikic can you review this?

[nikic]

These were case-insensitive previously, you can use _ci.

[Girgias]

Indeed, nice catch!

[nikic]

Suggested change

	zend_argument_value_error(1, "must be 'none', 'long' or 'entity'");
	zend_argument_value_error(1, "must be 'none', 'long', 'entity' or a valid codepoint");

Maybe? As is, it kinda sounds like you can only pass in those strings.

[Girgias]

Indeed, adjusted the message accordingly.