Consider not calling dlclose() for extensions

Description

PHP calls dlclose on extension as part of tearing down the runtime. However, dlclose can be really finicky; while I would hope extensions handle it fine (being that they are expected to be loaded and unloaded), the libraries that extensions often depend on often do not, and those can get unloaded as part of collecting garbage by the dynamic linker. If there are any dangling references to things in the unloaded memory, things can be catastrophic.

For example, one issue I've had was with the gnupg extension. It loads libgpg-error as a transitive dependency, and that sets up an atexit handler for clean up. But if the gnupg PHP extension gets unloaded by PHP, the dynamic linker can claim libgpg-error (since it wasn't referenced elsewhere), remove it from memory, and now the dangling atexit handler is all nulls. I have a patch inbound for libgpg-error, but it's one such example.

The problems with dlclose seem known; it was the cause of an OpenSSH exploit a year ago. Platform behaviour with dlclose also seems unpredictable; some platforms have specific criteria that will make them decide to close a library or not, which can be confusing. musl notably turns dlclose into a no-op considering the issues that dlclose brings in.

PHP already has a ZEND_DONT_UNLOAD_MODULES variable used for debugging contexts, since dlclose can confuse i.e. Valgrind. I suspect the main reason to unload modules is embedded SAPIs like i.e. the Apache module, if PHP gets unloaded and reloaded instead of the host going down with it. However, I'm not familiar enough with the embedded SAPIs outside of CLI/CGI to say how common this is.

(This might require an RFC.)

ファイルもテストも特定されていません。まず、dlclose 周辺のランタイムの拡張機能 teardown パスを追跡し、ZEND_DONT_UNLOAD_MODULES と組み込み SAPI がアンロードにどのような影響を与えるかを確認します。プラットフォームとライフサイクルの要件を明確にしたうえで、RFC が必要かどうかを判断します。アンロードポリシーと互換性の制約について合意できれば完了です。