Use 'break' instead of 'return' to abort the slurper thread.

With 'return' we wouldn't get the final 'info' message that the slurper has stopped,
and what the river status is now.
Make the 'tailerThreads' member final

'tailerThreads' is never changed after construction, although the content may change when the river
is started or stopped. This is however not covered by the 'volatile' keyword, and there is really no
need to allow concurrent modifications of the content (at this point).
Merge pull request #425 from Collaborne/tailer-threads-final

Make the 'tailerThreads' member final
Merge pull request #424 from Collaborne/slurper-break

Use 'break' instead of 'return' to abort the slurper thread.
Split the start/stop actions from the river start/close methods

The RiversService will invoke #start()/#close() when the river itself is started/stopped. However
we also have our internal status (controllable via REST, and driven by the StatusChecker), which is
semi-independent from that.

Split those two lifecycle actions:
River #start()/#close() now only manages the status thread itself
MongoDBRiver #internalStartRiver()/#internalStopRiver() is invoked by the status thread

This fixes first of all #406, as we're no longer deadlocking inside the initial listener thread. As a side-effect
it also fixes a potential inconsistency between the status of the river as seen by us, and the status of the river
as seen by the RiversService.
Start the status checker when the river is merely administratively disabled

A later REST request can be issues to start the river.
Do not force the river status in #close()

When we restart the river should come up in the same status as it was before, to switch a river
into the "stopped" state it must be explicitly done so using the REST API.
Change #internal{Start,Stop}River() to package protected

These methods aren't for external usage, but rather form a contract with the StatusChecker thread only.
Make it clear that "disabled" means "nothing will happen now"

Suggested-by: @benmccann
Fix the error messages to talk about "stop", matching the info message in the beginning.
Use a separate thread for starting up the river

The river status now changes from (nothing) to "START_PENDING" in the ES river startup code, to
"STARTING" while the startup thread is working on setting up the river, to "RUNNING" when the slurper/indexer
threads are active.

The process for stopping the river is unchanged up for the interrupting of the startup thread, should one be around.

The status checker avoids sending multiple start requests, and #internalStartRiver() ignores the request
when there is a non-null startupThread.
Remove an unused import
Use the parsed id values for the later assertions

* the 'id' variable was previously unused, but is helpful to validate that the correct document
  is returned
* the category id doesn't have to be hard-coded in the test (and the JSON document), but rather we
  can read it from the DBObject/DBRef and query using it
Merge pull request #431 from Collaborne/cleanup/initial-import-test-unused-imports

Remove an unused import
Merge pull request #432 from Collaborne/tests/dbref-test-stronger

Use the parsed id values for the later assertions
Use a separate logger for the StatusChecker

This helps distinguishing the logging from the checker about starting/stopping the river
from the actual information that the river is doing that.
Improve the logging

* unify the way we talk about the river
* use "begin of operation" and "end of operation" log statements
* move some log statements to more logical places

Suggested-by: @benmccann
Factor out common code for starting a Mongod process into methods
Use distinct labels for the tokumx and mongodb output
Rename #getStarter() to #newStarter() to make the purpose of the method clearer

Suggested-by: @benmccann