MFC r255521, r255526, r255707:

r255521 (jmg):

add support for writing the pid of the daemon program to a pid file so
that daemon can be used w/ rc.subr and ports can use the additional
functionality, such as keeping the ldap daemon up and running, and have
the proper program to signal to exit..

PR:		bin/181341
Submitted by:	feld

r255526 (joel):

mdoc: remove EOL whitespace.

r255707:

1. Properly clean pid files in the case of the error.
2. Write the supervisor pid before the restart loop, so we don't
   uselessly rewrite it after every child restart.
3. Remove duplicate ppfh and pfh initialization.
MFC r255714, r255716, r255717:

r255714:

Use cv_broadcast() instead of cv_signal() when waking up threads
waiting on an empty queue as the queue may have several consumers.

Before the fix the following scenario was possible: 2 threads are
waiting on empty queue, 2 threads are inserting simultaneously. The
first inserting thread detects that the queue is empty and is going to
send the signal, but before it sends the second thread inserts
too. When the first sends the signal only one of the waiting threads
receive it while the other one may wait forever.

The scenario above is is believed to be the cause of the observed
cases, when ggate_recv_thread() was getting stuck on taking free
request, while the free queue was not empty.

Reviewed by:	pjd
Tested by:	Yamagi Burmeister yamagi.org

r255716:

When updating the map of dirty extents, most recently used extents are
kept dirty to reduce the number of on-disk metadata updates. The
sequence of operations is:

1) acquire the activemap lock;
2) update in-memory map;
3) if the list of keepdirty extents is changed, update on-disk metadata;
4) release the lock.

On-disk updates are not frequent in comparison with in-memory updates,
while require much more time. So situations are possible when one
thread is updating on-disk metadata and another one is waiting for the
activemap lock just to update the in-memory map.

Improve this by introducing additional, on-disk map lock: when
in-memory map is updated and it is detected that the on-disk map needs
update too, the on-disk map lock is acquired and the on-memory lock is
released before flushing the map.

Reported by:	Yamagi Burmeister yamagi.org
Tested by:	Yamagi Burmeister yamagi.org
Reviewed by:	pjd

r255717:

Fix comments.