kernel - Attempt to fix tty race

* Opening /dev/tty is special cased to open the session ttyvp.  The
  VCTTYISOPEN flag is used on the session ttyvp to indicate this.

* There is a bug where the VCTTYISOPEN flag is set prior to calling
  VOP_OPEN() on ttyvp.  Because devfs's devfs_spec_open() (and
  also devfs_spec_close()) temporarily release the vnode lock
  on the vp (ttyvp in this case), setting the flag prior to
  the VOP_OPEN() can lead to a race where another process opens
  AND closes /dev/tty before our VOP_OPEN() executes.

  The racing open will see that the VCTTYISOPEN flag is already
  set and not issue a VOP_OPEN().  It's close will then VOP_CLOSE()
  ttyvp (which so far has not been opened by either process),
  which can kill the last open on ttyvp and cause the tty to
  disconnect.

  This race is very difficult to reproduce.  We were only able to
  reproduce it on monster (48-core opteron) which happened to
  access "/dev/tty" during a poudriere bulk build in a manner
  that was able to trigger the race.

* Fix this particular bug by not setting the VCTTYISOPEN flag
  until after VOP_OPEN() returns, then re-checking the flag to
  detect the race and clean-up/retry if a race is detected.

* TODO - This is not the only bug.  Unfortunately it is also quite possible
  for multiple threads/processes to open("/dev/tty", ...) simultaniously.
  There is only one VCTTYISOPEN flag so when this occurs and one process
  then close()s its descriptor, the VCTTYISOPEN flag is cleared.

  The other process or processes may then proceed to access ttyvp without
  an opencount guard.  When they close() the count is handled properly
  because the close() code detects that the VCTTYISOPEN flag was cleared.
  The problem is the unguarded read, write, and ioctl calls that might
  occur in the mean time.