[roll] Roll fuchsia [starnix][vfs] Avoid holding RCU read lock while dropping DirEntry

DirEntry::drop was acquiring an RcuReadScope to get a reference to the
parent DirEntry via parent_ref(). It then called parent.internal_remove_child(),
which acquires the children write lock. This can cause it to block while
holding an RCU read lock which should be avoided.

This may contribute to the linked bug given the following scenario:

1. Thread A (BlockingExecuto in the bug) holds the children write lock
   and blocks on FUSE (triggering clean_stack which blocks in the
   kernel, possibly on a user pager?).
2. Thread B (abbl in the bug) runs RCU callbacks, enters DirEntry::drop,
   and gets a parent reference under RCU read lock.
3. Thread B tries to acquire the parent children write lock to remove
   the child, and blocks because Thread A holds it.
4. Because Thread B blocks, it cannot exit drop and never releases the
   RCU read lock.
5. The RCU grace period is blocked waiting for Thread B.
6. Any other thread (say, the FUSE daemon) trying to exit a syscall
   blocks on rcu_grace_period via DelayedReleaser::apply which runs rcu
   callbacks.
7. Thread A never receives the FUSE reply and never releases the lock.

And we're deadlocked. Regardless though, we shouldn't be acquiring a
lock while holding an RcuReadScope, so this is likely required
regardless.

Instead, we use parent() in DirEntry::drop. parent() gets a strong
reference, but doesn't hold an rcu read_counter, so that
rcu_grace_period is able to run. If we block the on children lock, we
aren't holding the RCU read lock, breaking the deadlock cycle.

Original-Original-Bug: 513607124
Original-Original-Fixed: 514449784

Original-Original-Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/1620341
Original-Original-Revision: 3b5d6be01bbadd768777e59bb65af7860b45b8af
GitOrigin-RevId: fafb34c29acf74a43a9479c51fb29437b2a9a3d5
Change-Id: Idee281879f2a6b0e3c512aa7cae5e1ecd2dcb5ec