Tribe Node
The tribes feature allowed to create a tribe node that can act as a federated client across multiple clusters.

The tribe node configuration looks something like this:

```
tribe.t1.cluster.name: cluster1
tribe.t2.cluster.name: cluster2
```

The configuration above configure connections to 2 clusters, named `t1`, `t2`. It creates a "node" client to each (so by default, above, multicast discovery is used). The settings for each node client is extracted from the `tribe.[tribe_name]` prefix.

The way the tribe node works is by merging the cluster state from each cluster, and creating a merged view of all clusters. This means all operations work the same, distributed search, suggest, percolation, indexing, ... .

The merged view drops conflicted indices and picks one of them if there are 2 indices with the same name across multiple clusters.

By default, read and write operations are allowed. Master level read operations (cluster state for example), require setting the local flag to true (since there is no elected master). Master level write operations are not allowed (create index, ...).

The tribe node can be configured to block write operations `tribe.blocks.write` to `true`, and metadata operations by setting `tribe.blocks.metadata` to `true`.
closes #4708
[DOCS] Update cat/indices to reflect ?pri flag
apply comments on tribe code
add similar concrete path trie tests resolution
clean the params before running the next test
[DOCS] Added docs for tribe node

Related #4708
[DOCS] Fixed link to tribe.asciidoc
Remove `ElasticsearchInterruptedException` and handle interrupt state
correctly.

InterruptedExceptions should be handled by either rethrowing or
restoring the interrupt state (i.e. calling
`Thread.currentThread().interrupt()`). This is important since the
caller of the is method or subequent method calls might also be
interested in this exception. If we ignore the interrupt state the
caller might be left unaware of the exception and blocks again on
a subsequent method.

Closes #4712
Default to not accepting type wrapper in indexing requests

Currently it is possible to index a document as:

```
POST /myindex/mytype/1
{ "foo"...}
```

or as:

```
POST /myindex/mytype/1
{
    "mytype": {
        "foo"...
    }
}
```

This makes indexing non-deterministic and fields can be misinterpreted
as type names.

This changes makes Elasticsearch accept only the first form by default,
ie without the type wrapper. This can be changed by setting
`index.mapping.allow_type_wrapper` to `true`` when creating the index.

Closes #4484
Improve support for partial snapshots

Fixes #4701. Changes behavior of the snapshot operation. The operation now fails if not all primary shards are available at the beginning of the snapshot operation. The restore operation no longer tries to restore indices with shards that failed or were missing during snapshot operation.
Added stopwords: _none_ to the docs #329
Referring to stop analyzer for stopword docs #329
Fix Release tool to run smoke tests off tags

this commit allows to run the release tool for smoke
testing without being on the actually released branch.
This commit also added a list of plugins that will be installed
for smoke testing to see if the plugin startup mechanism works
correctly.
Add a new FetchSubPhase, FieldDataFieldsFetchSubPhase
Parse `fielddata_fields` elements
Correctly return value from SubFetchPhase
Add field data service
Look up from context
Correctly retrieve field from fielddata cache
Add methods to builder for `fielddata_fields`