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.
Merge branch 'split-river-start_stop' into master-collaborne

Conflicts:
	src/main/java/org/elasticsearch/river/mongodb/MongoDBRiver.java