Fix GH-7939: Cannot unserialize IntlTimeZone objects

[cmb69]

As it is now, IntlTimeZone, IntlCalendar and IntlDateFormatter
instances can be serialized, but the representation is meaningless, and
unserialization yields uninitialized/unusable objects. To prevent
users from noticing this too late, we deny serialization of such
objects in the first place.

---

Note that I targetted PHP-8.1 for convenience, and that I didn't check other Intl classes for now which may have the same issue. For now, I'm interested whether we want to go this route (note that any serialization attempt will throw an Error now), or whether we actually want to implement proper (un)serialization for these classes.

[iluuu1994]

The downside is that this would make the whole serialization fail for cases where IntlTimeZone might be embedded in a nested structure but otherwise disregarded.

[cmb69]

@iluuu1994, indeed. But the alternatives would be to implement proper (un)serialization (not sure if feasible for all Intl classes), or to only issue E_WARNING (what might be converted to an exception by the error handler), or to keep it as is (what might be the worst option). Or are there other options?

[iluuu1994]

@cmb69 I think making it non-serializable is ok but might be a bit disruptive for a patch. Then again I have very little experience with PHP releases so you probably know better than me 😄

[cmb69]

Okay, makes sense. I've retargeted to "master".

[iluuu1994]

These are also not serializable:

• IntlCalendar
• IntlGregorianCalendar
• IntlDatePatternGenerator
• Locale (should __construct also be private as this is supposed to be a static class?)
• Normalizer (same as above)
• IntlChar (same as above)

[cmb69]

Thanks for checking, @iluuu1994!

IntlCalendar and IntlGregorianCalendar are already covered (1st commit). Locale, Normalizer and IntlChar are indeed static classes, so their constructor should be private; serialization "works" though; I see that as a different topic (as well as IntlIterator not being abstract, although you can't use any of its instances). I shall catch up on IntlDatePatternGenerator (which it is not yet documented).

[iluuu1994]

Alright, I think if we make IntlDatePatternGenerator non-serializable (as it does store the locale and thus won't work if unserialized) this PR should be ready.

[cmb69]

The CI fails appear to be unrelated.

[iluuu1994]

I think this can be merged