Add DH-CHAP authentication key operations for NVMe-oF connections:

- generateDHCHAPKey(): Creates NVMe spec-compliant keys in
  DHHC-1:hash:base64:crc32 format (supports SHA-256/384/512)
- GetOrCreateDHCHAPHostKey/SubsystemKey(): Manages per-connection keys
- buildDHCHAPKeyID(): Generates unique key IDs using nodeID and
  hashed subsystemNQN (e.g., nvmeof-dhchap-host-node1-abc123)

Keys are stored/retrieved via SecurityKeyNVMEOFManager using KMS
encryption. Each node-subsystem pair gets a unique authentication key.

Signed-off-by: gadi-didi <gadi.didi@ibm.com>

- get the dhchap mode- it can be
"none", "unidirectional", "bidirectional", or empty
and store it in volumeContext (for ControllerPublishVolume())
- get authenticationKMSID var. also can
be empty. and store it in volumeContext.

Signed-off-by: gadi-didi <gadi.didi@ibm.com>

adding these vars because there are going to be in used
in removing dh-chap keys- in ControllerunPblishVoluem().

Signed-off-by: gadi-didi <gadi.didi@ibm.com>

Implement kms.DEKStore using RBD image metadata for testing/development.
Stores encrypted DH-CHAP keys as metadata entries in the backing RBD image.

- Keys stored with prefix "nvmeof.csi.ceph.com/" to distinguish from
  volume encryption and NVMe-oF resource metadata
- Used with "metadata" KMS type (secrets-metadata) for POC/testing
- Production deployments should use Vault KMS with integrated storage

Signed-off-by: gadi-didi <gadi.didi@ibm.com>

add instace of SecurityKeyNVMEOFManager into
controller server struct.
also add getOrInitSecurityKeys() ,
lazy init for SecurityKeyNVMEOFManager struct.
this field is the manager of sercurity things like dh-chap
psk\tls.

Signed-off-by: gadi-didi <gadi.didi@ibm.com>

Implement DH-CHAP authentication for NVMe-oF host connections with
pluggable KMS backend support for secure key management.

Changes:
- setupDHCHAPKeys(): Initialize KMS, retrieve/generate host authentication
  keys, and configure DEKStore (RBD metadata for testing, Vault for prod)
- cleanupDHCHAPKeys(): Remove DH-CHAP keys during ControllerUnpublishVolume
- Update AddHost() to accept optional DH-CHAP host key parameter
- Add dhchapMode volume context parameter (none/unidirectional/bidirectional)

Authentication flow:
1. Parse dhchapMode from volume context (defaults to "metadata" KMS)
2. Initialize SecurityKeyNVMEOFManager with KMS credentials
3. For metadata KMS: Set RBD volume as DEKStore (test mode only)
4. GetOrCreateDHCHAPHostKey() retrieves existing or generates new key
5. Pass encrypted key to gateway AddHost() call

Keys are stored per node-subsystem pair, encrypted with KMS (KEK from
K8s Secret), and persist across volume operations. Production deployments
should use Vault KMS with integrated DEK storage.

Signed-off-by: gadi-didi <gadi.didi@ibm.com>

Implement DH-CHAP authentication for NVMe-oF initiator connections
with support for both unidirectional and bidirectional modes.

Changes:
- setupDHCHAPAuth(): Retrieve host/subsystem keys from KMS and configure
  ConnectRequest with authentication parameters
- Pass dhchapMode from volume context through connection flow
- Add --dhchap-secret and --dhchap-ctrl-secret to nvme connect command
- Support RBD metadata DEKStore (testing) and Vault KMS (production)

Authentication flow:
1. NodeStageVolume receives dhchapMode from volume context
2. Initialize SecurityKeyNVMEOFManager with same KMS as controller
3. Retrieve existing DH-CHAP keys (generated during ControllerPublishVolume)
4. For unidirectional: Add host key to nvme connect
5. For bidirectional: Add both host and subsystem keys

Signed-off-by: gadi-didi <gadi.didi@ibm.com>