https://github.com/varnishcache/varnish-cache/issues/3051

The thought was to shorten the time spent under the lock. But it
actually introduces a race.

And update related parts of the docs.

POSIX requires that a file description is referenced by mmap(2),
so the refcount does not reach 0 when the file is deleted while
it is still mapped. So POSIX-compliant systems can be expected to
retain the mapping after file deletion.

Unless the VMOD goes to the trouble of copying the file, the safe
way to update it is to delete it, then write a file with the same
name with the new contents. A check may happen to run between
deletion and the new write. But because of the property mentioned
above, this is not a real problem for memory-mapped files.

So the VMOD will work according to these rules:

- If a check cannot read a file due to ENOENT, it is not an error.
  (It is an error if the file does not exist on initial read.)
  In that case, the file is considered unchanged -- the current
  mapping continues as the cached file contents.

- This means that for the VMOD, a deleted file is *not* considered
  to be in error, provided it could be read initially (that is, it is
  already mapped).

- We set a flag when the file is deleted, so that the condition
  can be detected.

- Users are advised in the docs that the "delete, then write"
  procedure is the *only* method for updating the file that the
  VMOD supports. Other methods may work, some of the time, but
  you do it differently at your own risk.

Also, access(2) is not a reliable means to determine if the file
can be read and mapped, because if checks permissions against
the real UID/GID, whereas open(2) depends on effective UID/GID.

So:

- checks begin with open(2), then use fstat(2) for the stat check.

- Path searches are done by attempting open(2) with the filename
  on each directory in the path.

distcheck does not allow writes into the build directory, so we
can't use ${testdir}.

Prove that next_check() really runs when there is an error.