Fix GH-23276: Collect ZipArchive subclasses holding their own streams

[LamentXU123]

I actually doubt this is a bug in the Zend engine. But since I am not familiar with how Zend GC works, I'd fix this is in a completely ext/zip way, to replace the stream's reference to the ZipArchive object with a refcounted archive state, so a stream can keep the underlying zip_t without preventing its owning ZipArchive object from being GC-ed.

There can be better fixes, as I said, to fix in the Zend engine. But I think this is a very rare case happening in the zip extension, so I'd rather re-implement it than touching the Zend core, so we don't bother other code.

Fixes GH-23276

[devnexen]

There can be better fixes, as I said, to fix in the Zend engine. But I think this is a very rare case happening in the zip extension, so I'd rather re-implement it than touching Zend core, so we don't bother other code.

It is probably best for a stable branch IMO, that being said I ll review it sometime this weekend.

[devnexen]

I would suggest one thing after a quick look. Keep at it, this refcounting approach is likely to cause indirect issues.

[ndossche]

I think this is wrong, I believe you need a get_gc object handler for ZipArchive.

[LamentXU123]

Apparently I have to take some time to study Zend GC. It seems like we don't have a reasonable way to bypass this entirely.