Prevent res_timing_pthread from blocking callers

There were several reports of deadlock when using
res_timing_pthread. Backtraces indicated that one thread was blocked
waiting for the write to the pipe to complete and this thread held
the container lock for the timers.  Therefore any thread that wanted
to create a new timer or read an existing timer would block waiting
for either the timer lock or the container lock and deadlock ensued.

This patch changes the way the pipe is used to eliminate this source
of deadlocks:

1) The pipe is placed in non-blocking mode so that it would never
block even if the following changes someone fail...

2) Instead of writing bytes into the pipe for each "tick" that's
fired the pipe now has two states--signaled and unsignaled. If
signaled, the pipe is hot and any pollers of the read side
filedescriptor will be woken up. If unsigned the pipe is idle. This
eliminates even the chance of filling up the pipe and reduces the
potential overhead of calling unnecessary writes.

3) Since we're tracking the signaled / unsignaled state, we can
eliminate the exta poll system call for every firing because we know
that there is data to be read.

(closes issue ASTERISK-21389)
Reported by: Matt Jordan
Tested by: Shaun Ruffell, Matt Jordan, Tony Lewis
patches:
  0001-res_timing_pthread-Reduce-probability-of-deadlocking.patch uploaded by sruffell (License 5417)

(closes issue ASTERISK-19754)
Reported by: Nikola Ciprich

(closes issue ASTERISK-20577)
Reported by: Kien Kennedy

(closes issue ASTERISK-17436)
Reported by: Henry Fernandes

(closes issue ASTERISK-17467)
Reported by: isrl

(closes issue ASTERISK-17458)
Reported by: isrl

Review: https://reviewboard.asterisk.org/r/2441/


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/1.8@386109 f38db490-d61c-443f-a65b-d21fe96a405b