Support ZendStr keys when inserting into ZendHashTable

[hwawshy]

Hi,

First of all thank you to the maintainers for all your work on ext-php-rs.

I was wondering if it would make sense to support using ZendStr as keys when inserting values into ZendHashTable. One use case that I ran into is using interned strings as keys.

Corresponding Zend API would be functions like zend_hash_add_or_update, zend_hash_update, zend_hash_add, ..etc.

Would be happy to try my hands at a PR if you think it would make sense.

Thanks

[ptondereau]

Thanks for proposing this!

The current zend_hash_str_* path does a fresh zend_string_init (emalloc + memcpy + hash recomputation) on every new bucket. Letting callers pass a zend_string directly hits zend_hash_update and friends, which:

• reuse the cached ZSTR_H(key) (no re-hash),
• for interned keys, store the pointer with no allocation, no copy, and keep HASH_FLAG_STATIC_KEYS set,
• for refcounted keys, just bump the refcount.

I can see real wins for interned hotkeys cached at MINIT, mangled property keys (\0Class\0prop), and zend_string round-tripping from PHP into a new array.

A few concerns for the PR:

1. Additive, not a replacement. We should keep the &str and String paths untouched.
2. Scope to insert/find/exists/del. Adding an ArrayKey::ZendString(&'a ZendStr) variant (or Cow<'a, ZendStr>), expose zend_hash_add_or_update / update / add / add_new / find / del in allowed_bindings.rs, route the matches. Then, leave the iterator side for a follow-up because it changes the return type and lifetimes.
3. Document refcount semantics. zend_hash_add does the addref itself for non-interned strings.
4. Note the mixed-mode penalty. One non-interned key clears HASH_FLAG_STATIC_KEYS.
5. Include a microbench. Inserting N keys with &str vs interned &ZendStr, then iterating and destroying.

Happy to review a PR!