Allow users to explicitly define index management operations

[danielmitterdorfer]

At the moment, Rally auto-manages indices, which basically means that it creates and deletes the affected indices at the start of a benchmark. This works fine for our Elasticsearch development benchmarks but there are other situations where users want more explicit control.

Hence, we should provide a couple of index management APIs as Rally operations:

• Create index (with mappings)
• Create index templates
• Delete index
• Rollover index (obviously this will only work for ES 5 or later)

We should also improve the existing indices stats operation to include data from the response in the meta-data (depending on the performance impact this needs to be enabled with a flag).

Tasks:

• Establish a notion of an administrative task (executed but not measured) Don't measure every operation #361
• Rewrite all administrative operations that are currently done implicitly by Rally as custom runners (leveraging Allow to retry operations (internally) #363 for some).
• Adapt track loading code to amend the track with these implicit operations by default.
• Have a means to disable this behavior and define track management operations explicitly (per challenge?).

[danielmitterdorfer]

As a preparation, we will allow (selected) runners that are defined by Rally core to use retries (either on timeout or application "error") (see #363).

The first operation that will benefit from this change is most likely the cluster health check that is currently hard-coded.

[danielmitterdorfer]

For the migration, we should also keep elastic/rally-tracks#37 in mind: The cluster health check in tracks should take only the track-relevant indices into account.