update to latest jsr166
latest jsr166 upgrade only compiled with 1.7
cache recycler now node/client level component
remove unused class
search reducer to use atomic reference arrays
move away from maps to correlate between responses from different shards to unique incremental integer representing a shardRequestId (unique for the specific search request)

 this allows to no longer require using maps (or CHM), and simply use atomic reference arrays, which rely on volatiles. it also removes the need to use a cache for heavy data structures since we don't really have them around anymore...
multiget requests which referred to missing indexes blocked and never returned.
Rename DocIdAndVersion.reader to DocIdAndVersion.context to avoid confusion.
Rename IndicesAdminClient#existsAliases to IndicesAdminClient#aliasesExist.
Closes #3330
move the fields doc queue to a better package location
fix term vector api retrieved wrong doc

The previous loading of term vectors from the top level reader did not use the
correct docId. The docId in Versions.DocIdAndVersion  is relative to the segment
reader in Versions.DocIdAndVersion and not to the top level reader.
Consequently the term vectors for the wrong document were returned if the
document was not on the first segment of the shard.
move to use ScoreDoc/FieldDoc instead of our wrappers
now that we have the concept of a shardIndex as part of our search execution, we can simply move to use ScoreDoc and FieldDoc instead of having our own wrappers that held the info
Also, rename shardRequestId where needed to be called shardIndex to conform with the variable name in Lucene
Renamed IndicesGetAliases* classes to begin with GetAliases*
Add found field for bulk deletes. Closes #3320
Set spare becore comparing comparator bottom value

The actual documents value was never calculated if setSpare wasn't called
before compareBottom was called on a certain document.

Closes #3309
Debian/Redhat package improvments

This decision helps people who want to rollout the oracle java without having an openjdk java installed.

* Removed any hard dependency on Java in the debian package
* The debian init script does not check for an existing JAVA_HOME anymore
* Debian and RedHat initscripts now exit if they do not find a java binary (instead of starting elasticsearch in the background and swallowing the error as there is no way to log it in that case)
* Changed the debian init script to rely on the pid file instead of the argument name of process
* Added a useful error message in case no java binary is available (in elasticsearch shell script)

Closes #3304
Closes #3311
fixed existing test and linked it to its issue
Fix xcontent serialization of timestamp/routing index field

The index field was serialized as a boolean instead of showing the
'analyed', 'not_analzyed', 'no' options. Fixed by calling
indexTokenizeOptionToString() in the builder.

Closes #3174
Add the ability to ignore or fail on numeric fields when executing more-like-this or fuzzy-like-this queries.

More-like-this and fuzzy-like-this queries expect analyzers which are able to
generate character terms (CharTermAttribute), so unfortunately this doesn't
work with analyzers which generate binary-only terms (BinaryTermAttribute,
the default CharTermAttribute impl being a special BinaryTermAttribute) such as
our analyzers for numeric fields (byte, short, integer, long, float, double but
also date and ip).

To work around this issue, this commits adds a fail_on_unsupported_field
parameter to the more-like-this and fuzzy-like-this parsers. When this parameter
is false, numeric fields will just be ignored and when it is true, an error will
be returned, saying that these queries don't support numeric fields. By default,
this setting is true but the mlt API sets it to true in order not to fail on
documents which contain numeric fields.

Close #3252