If a fork happens while some thread is sending metrics and holds one
of the locks, the lock would remain locked in the child process and
would deadlock, either in the post_fork handler (when the post_fork
hook tries to close the socket), or later (when user code tries to
send a metric).

Work around the issue by resetting the socket and buffer locks in the
child process. If those were locked in the parent at the time of the
fork, the internal client state may be inconsistent, so we reset it as
well.

With config lock, we can not reset the state to some known good state,
and to avoid problems when fork is called while a thread modifies the
client configuration, the config lock will be held across fork. Both
the client and the parent can safely unlock it afterwards.