Fix multi-cluster attribute check for wrapped runners

[b-deam]

With this commit we fix an existing bug where the multi-cluster attribute of
wrapped runners were not checked properly.

[pquentin]

Thanks! I'm wondering about the general direction here. Looking at #488 it looks like multi-cluster support was meant for custom runners that wanted to do different operations for each cluster.

Here you want to do the same operation for all clusters, which begs the following questions:

1. What if you don't actually want to delete data streams in all clusters?
2. This does not generalize very well: are we going to add 100 lines of code every time we want an operation to work on all clusters?

It seems to me that we can address both those concerns by adding a new operation say all-clusters that will run a given operation on all clusters. Maybe I'm over thinking it: I'd like to know what @dliappis thinks, as he added #488.

(Also, if this was split in two commits or two PRs, we could have merged the first part! It's always suspicious when a PR or commit contains the word "and".)

[b-deam]

Thanks! I'm wondering about the general direction here. Looking at #488 it looks like multi-cluster support was meant for custom runners that wanted to do different operations for each cluster.

Here you want to do the same operation for all clusters, which begs the following questions:

1. What if you don't actually want to delete data streams in all clusters?
2. This does not generalize very well: are we going to add 100 lines of code every time we want an operation to work an all clusters?

It seems to me that we can address both those concerns by adding a new operation say all-clusters that will run a given operation on all clusters. Maybe I'm over thinking it: I'd like to know what @dliappis thinks, as he added #488.

I agree with these comments, and therefore reverted the DeleteDataStream changes in bd11ad3 and updated #1562 with more details on more general approach to handling multi-cluster support for runners in the future. For now (to unblock me) I'll add the required logic to the custom FollowIndex runner merged via elastic/rally-tracks#293.

(Also, if this was split in two commits or two PRs, we could have merged the first part! It's always suspicious when a PR or commit contains the word "and".)

Agreed and apologies, I kept the 'bug' fix in 287fbc0. I've renamed the PR title to match.

[pquentin]

Thanks! LGTM. I left two small comments, feel free to merge after addressing them.

[pquentin]

Thanks! LGTM.