[docs] add 2d vis for decay functions and parameters

closes #8420
Docs: Removed old coming/added tags
Scripting: Add score() back to AbstractSearchScript

See #8377
closes #8416
closes #8417
Rest API: indices.delete should have "index" as a required param
Core: add max_determinized_states to query_string and regexp query/filter

This prevents too-difficult regular expressions from consuming
excessive RAM/CPU; the default max_determinized_states is 10,000 (same
as Lucene) but query_string and regepx query/filter can override
per-request.

The also upgrades to a new Lucene 5.0.0 snapshot.

Closes #8386

Closes #8357
remove wrong repository
Internal: extend refresh-mapping logic to the _default_ type

When data nodes receive mapping updates from the master, the parse it and merge it into their own in memory representation (if there). If this results in different bytes then the master sent, the nodes will send a refresh-mapping command to indicate to the master that it's byte level storage of the mapping should be refreshed via the document mappers. This comes handy when the mapping format has changed, in a backwards compatible manner, and we want to make sure we can still rely on the bytes to identify changes.  An example of such a change can be seen at #4760.

This commit extends the logic to include the `_default_` type, which was never refreshed before. In some unlucky scenarios, this caused the _default_ mapping to be parsed with every cluster state update.

Closes #8413
Test: switch to TRACE logging for some components
Test: restore logging to prior state
Query: add option for analyze wildcard/prefix also to simple_query_string query

The query_string query has an option for analyzing wildcard/prefix (#787) by a best effort approach.

This adds `analyze_wildcard` option also to simple_query_string.

The default is set to `false` so the existing behavior of simple_query_string is unchanged.
Refactor term analysis for simple_query_string prefix queries

Also fixes an issue where the token stream could be non-closed if an
exception occured.
[CORE] Intorduce shards level locks to prevent concurrent shard modifications

Today it's possible that the data directory for a single shard is used by more than on
IndexShard->Store instances. While one shard is already closed but has a concurrent recovery
running and a new shard is creating it's engine files can conflict and data can potentially
be lost. We also remove shards data without checking if there are still users of the files
or if files are still open which can cause pending writes / flushes or the delete operation
to fail. If the latter is the case the index might be treated as a dangeling index and is brought
back to life at a later point in time.

This commit introduces a shard level filesystem lock that prevents modifications to the shard data
while it's still in use. Locks are created per shard following this structure:
  `{data.dir}/locks/{index.name}/shard_{id}`

This commit also adds infrastructure that checks if all shard locks are released after tests.