feat(kv): support for migrations

[GeorgeMac]

This change introduces a new kv.Migrator and associated migrations types.
This change sets a new precedent for how we introduce new resource types and indexes into the kv package within InfluxDB.

The new Migrator type adds support for managing these ongoing types of change as migrations. A migration is effectively a change to kv schema (defined as an Up(...) function operation) and a definition of how to revert the operation (defined as a Down(...) function operation).

The kinds of "schema" changes expected to be managed by these types (in the near-team) are KV buckets and indexes.

By default, inmem and bolt kv implementations should continue to operate as they always have. On initialization of the KV service, when backed by one of these KV stores implementations the migrations are all applied automatically.

Outstanding:

• Get feat(kv): index utility type #16910 shipped
• Consider either moving the introduction of the new indexes into own PR.
• move tests into testing package and invoke for both inmem and bolt.

Checklist:

• CHANGELOG.md updated with a link to the PR (not the Issue)
• Well-formatted commit messages
• Rebased/mergeable
• Tests pass
• http/swagger.yml updated (if modified Go structs or API)
• Documentation updated or issue created (provide link to issue/pr)
• Signed CLA (if not already signed)

[jsteenb2]

be good to make this an inflxudb.Error type with the necessary code/msg

[GeorgeMac]

This kind of error shouldn't really ever reach a user

[GeorgeMac]

It happens on initialize or through manual invocation via a cli.

[brettbuddin]

Minor questions. Take them or leave them.

[affo]

@GeorgeMac this is huge.

I really like it, thanks for doing this.

The framework is pretty elastic and enables all sorts of migrations given that you have access to the underlying kv in Up().

In this scenario migrations would need to be applied via CD, right?

Up() and Down() are in the codebase, and not part of the Migration object itself.
So, to enable a migration, you'll need to code it and deploy it, or am I missing something?

We could take this offline and think about how we could expose this as an HTTP service, what do you think? This way one could run migrations independently from code base changes.