Match .kibana index and don't clean them up

[pathikritmodak]

From version 6.5.0 kibana indexes are being stored as .kibana_1 .. kibana_N
Hence regexmatching indexes which start as .kibana, as with the current approach they get deleted and you lose your saved objects
https://www.elastic.co/guide/en/kibana/current/upgrade-migrations.html

[Nuru]

The issue of what to do with the .kibana_N indexes is not clear cut. The Kibana 6.5 docs suggest that you will accumulate multiple indexes over time (.kibana_1, .kibana_2, .kibana_3, ...) and may or may not want to keep older versions to enable rolling back to previous versions.

This PR proposes never deleting any .kibana_N indexes, which is unlikely to be the right thing to do. By the time someone is at .kibana_5 they probably can do without .kibana_1. Maybe this lambda should never delete them, and users should be forced to delete them manually, or maybe not.

(Also, the regex used by this PR is overbroad, but that is a minor thing compared to actually figuring out the correct desired behavior.)

The solution upstream is to explicitly list which indexes to skip when specifying delete all. That is dodgy, in that it makes it most likely that the newest and in-use index could get deleted if you forget to update the skip list first.

For now, #14 excludes .kibana_1, but we still recommend explicitly listing which indexes to delete (e.g. "logstash") instead.

I will leave this issue open for further discussion, for now at least.