devfs: Fix FLASTCLOSE handling

[markj]

Summary

devfs uses the device's usecount to determine how many times a device
has been opened. If it transitions 1->0, then we should invoke d_close
(assuming D_TRACKCLOSE isn't set).

But, we bump the usecount before calling d_open. Suppose a thread races
to open a device while a different thread is closing it. The first
thread may bump usecount 1->2, and then the closing thread decrements it
2->1. Then, if the open fails, we will decrement again 1->0 but d_close
is not invoked at all.

Fix the problem by incrementing usecount only after a succesful open. I
believe this does not introduce any new races: the usecount is only used
to decide whether to revoke or not, and the session holds an additional
ref via devfs_ctty_ref(). Note however that d_close(FLASTCLOSE) can
now race with d_open().

[kbowling]

It fixes the failed open race (from the mentioned issue) but I was able to trigger the following with an LLM mock:

At the new devfs_usecount_add() near line 1329:

1. A already has the device open; usecount is 1.
2. B’s d_open() succeeds, but B has not reacquired the vnode lock or incremented usecount.
3. A closes: devfs observes the last reference and calls d_close().
4. B increments usecount and returns success—after device teardown.

TTY is a concrete affected consumer: ttydev_close() (sys/kern/tty.c:378) clears its opened flags and releases queues and subsequent operations fail the ttydev_enter() (sys/kern/tty.c:221) check with ENXIO. With the old ordering, B already contributed a reference and A would skip d_close().

[markj]

Serialize d_open and d_close when a FLASTCLOSE close is in progress.

This is unsatisfying, but I can't see any other way to fix the race.
The right solution is to handle this problem in drivers and make
D_TRACKCLOSE behaviour universal.

[kbowling]

This now handles the close-first ordering, but the open-first ordering from my example still appears possible. Once an opener passes the SI_LASTCLOSE check, nothing records its presence until after d_open returns and the vnode lock is reacquired. A last close can still run in that interval. We need protection in both directions checking SI_LASTCLOSE only before d_open does not establish mutual exclusion.