initializer/cryptsetup: rework bash entrypoint

[jmxnzo]

Similarly to #1161 , this PR serves as a preliminary step toward moving cryptsetup to a subcommand of the initializer binary. Before translating the Bash entrypoint (used in the initializer binary after merging #1161) into Go code, the script was reworked to allow a cleaner integration of the volume encryption.
There were a few peculiarities in the cryptsetup LUKS standardization that have not been fully addressed in the current version of the entrypoint:

• key is equivalent to passphrase (see the LUKS EXTENSION section in the cryptsetup manual).
• When using the --key-file flag with cryptsetup, the file's contents are unexpectedly treated as a passphrase rather than a cryptographic key.
• Using the keyfile as passphrase won't result in higher entropy of the encryption key. As a result, we can directly use the workload secret and UUID without performing key derivation, because there is no straightforward way to avoid the built-in PBKDF for LUKS in cryptsetup.

e2e/volumestatefulset: https://github.com/edgelesssys/contrast/actions/runs/12764474415/job/35576714135

[burgerdev]

lgtm, but I'd like to get a second opinion from @3u13r.

[jmxnzo]

As described in Figure 4: pseudo code for key creation each PBKDF2 derived encryption key used to encrypt the AFSplit of the master key, is derived by the passphrase and a 32 byte salt from a random source.
For a key slot, all parameters how to decrypt its key material with a given user password are
stored in the phdr (f.e. salt, iteration depth) with the corresponding encrypted master key stripes. Thus the random salt fulfills the same function as including the UUID into our passphrase and similarly adds the uniqueness of the disk to the encryption key. Therefore to maintain readability, we dropped the logic of doing the first key initialization to get the UUID and rekeying afterwards. @3u13r Please give feedback on this code change again!

[3u13r]

LGTM