API: Define RotateEncryptionKeys action interface

[dramaticlly]

First step of #18240 to define action interface to allow rewrap of encrypted iceberg table.

Added configurable depth level to control how deep the encryption key of iceberg metadata shall be regenerated.

• KEK: where key-encryption-key is regenerated and stored in table metadata, manifest-list key is unwrapped with old KEK and rewrapped with new KEK. This can be done in table API with only change to metadata.json
• SNAPSHOT_KEY: where key-encryption-key, manifest-list key are regenerated, existing manifests key in manifest-list are rewrapped. This generates a new snapshot and a new metadata.json, all existing manifests are carried over.
• MANIFEST_KEY: where key-encryption-key, manifest-list key as well as manifest keys are all regenerated, every data and delete live entry in manifests are rewrapped. All metadata layer keys are replaced. Requires engine to distribute the work and expect a new set of manifests, a new snapshot and new metadata.json

Thought about the option to introduce a new flag on the existing RewriteManifests action and procedure and it was discarded to avoid combining security operation inside a re-clustering/optimizing call, also rewrite manifests can only focused on single partition spec.

[dramaticlly]

@ggershinsky do you think if it's ok to start with KEY_ENCRYPTION_KEY and MANIFEST_KEY depth level? We can always add data file key later in the enum if there's need for the expensive key replacement.

[ggershinsky]

sure, makes sense

[ggershinsky]

there should also be a MANIFEST_LIST_KEY level, between these two?
KeyRegenerationLevel : KEY_ENCRYPTION_KEY, MANIFEST_LIST_KEY, MANIFEST_KEY, DATA_KEY
(ROOT_MANIFEST for v4?)

[ggershinsky]

Thinking of this, we might want to refocus / rename the action, from rewrap to rotate, for the following reasons:

• KeyRegeneration is basically key rotation
• "key rotation" is more intuitive and better known than "key rewrapping"
• data file reencryption does not map well to a key rewrapping hierarchy

[dramaticlly]

Thanks @ggershinsky! I added the SNAPSHOT_KEY as new enum to represent both manifest-list in v1-3 and root manifest in v4 and renamed to RotateEncryptionKeys as suggested. I think it make more sense now: for hierarchical iceberg metadata, each encryption key stored one level above what it encrypts. So regenerate of the key at level X apply to all keys traversed from root to X, the file at level X is replaced with a regenerated key but its content is unchanged (rewrap)

[ggershinsky]

Yep, I think SNAPSHOT_KEY is a better name