slop pusher dead locks with workers, insane timeout

1) Previously slop pusher used worker threads per node to stream slops.
SlopPuhserJob used a cached thread pool to create these worker threads.
When you queue up more work than the number of max allowed threads in
cached thread pool, it blocks until previous thread completes.
SlopPusher job used synchronous queue to communicate with these worker
threads. Java Synchronous queue models the producer/consumer problem
where both of them will wait for the counter part and proceed forward.
Slop pusher used a timedout put for giving work, but it used a blocking
put for sending the termination message.

There are multiple ways that this can deadlock

1) Let us say that you are allowed 10 threads in cached thread pool. But
you have slops for 15 nodes. Now after streaming slops, if you send the
termination messages in random order, you might wait for a worker which
is not yet run. Other workers are waiting for termination messages and
it will deadlock.
2) If you are streaming slop on a worker and you ran into an exception.
The worker will never wait for the termination message, but server will
still try to send one, depending on the place where it is at.

The code is re-written to not to use worker threads. Though in the
previous model there were multiple threads in 99% of the cases only one
of them will make progress and others will wait for main thread to
allocate work. So the code was rewritten where all the processing
happens in the SlopPusher job itself.

Will have to put through integration testing and various scenario
testing before the fix can be released to the prod.

2) AdminTimeout is set to 24 hours. If a node is hung, machine is up, but
process has crashed it will still accept the connection but never
responds. In that case it will cause 24 hours for the protocol
negotiation to time out and it can cause the slopPusher to hang as well.