Fix GH-21682: Add NOT_SERIALIZABLE to ZipArchive, XMLWriter, XMLReader, SNMP, tidy, tidyNode

[iliaal]

Fixes #21682

Six classes wrap native C handles but allow serialization. Unserializing them produces objects with NULL internal pointers.

Segfault:

• tidyNode (ext/tidy): crashes on hasChildren(), dangling TidyNode pointer

Silent data loss:

• ZipArchive (ext/zip): numFiles returns 0, archive contents gone
• tidy (ext/tidy): body() returns NULL, cleanRepair() no-ops
• SNMP (ext/snmp): methods run against a dead session without error

Throws on use:

• XMLWriter (ext/xmlwriter): methods throw "Invalid or uninitialized XMLWriter object"
• XMLReader (ext/xmlreader): read() throws "Data must be loaded before reading"

Adds @not-serializable to all six so serialize() throws instead of producing broken objects.

Two existing UAF exploit tests (bug72479.phpt, bug72434.phpt) relied on unserialize() instantiating SNMP and ZipArchive objects. With NOT_SERIALIZABLE, unserialize() rejects these classes outright, removing the UAF vector.

[ndossche]

One thing to keep in mind is that it may introduce issues analogous to #8996
Perhaps the not-serializable flag is not the right way to do it, I was never really convinced that also blocking children is the right thing to do.

[iliaal]

Serializing these classes today: tidyNode segfaults on hasChildren(), ZipArchive/tidy silently lose state, XMLWriter/XMLReader throw on every method call. None produce a usable object.

Re child classes and GH-8996: only tidyNode is final, but unlike DOM none of these classes can capture or restore their internal C state. DOMDocument has saveXML()/loadXML(), which makes SerializableDomDocument viable. These classes have no equivalent. The underlying handles (xmlTextWriterPtr, TidyDoc, libzip archive, SNMP session) are opaque. A child adding __serialize would track its own state and rebuild from scratch on wakeup, not serialize the parent. The GH-8996 pattern doesn't apply here in practice.

Happy to switch to the DOM-style custom handler if you'd prefer that over NOT_SERIALIZABLE, I do think though it introduces complexity for little meaningful value though.

[ndossche]

Fair enough, see my nitpick remark.

[ndossche]

This test should be moved to ext/zip/tests

[iliaal]

fair enough, moved as asked.

[DanielEScherzer]

Re child classes and #8996: only tidyNode is final, but unlike DOM none of these classes can capture or restore their internal C state

ZipArchive will have a way to capture this soon with #21497, see https://github.com/tstarling/php-src/blob/de15d91b44fe56d7e02c4ada8e6e7c0ea13ef146/ext/zip/tests/ZipArchive_closeString_basic.phpt, so allowing subclasses to be serialized might be useful - can you split out the ZipArchive changes? In the absence of a maintainer for ext/zip we should at least give more consideration after #21497 before deciding to prevent subclass serialization