Fix incorrect storage protocol usage when multiple appliances are defined in secret

[santhoshatdell]

Description

Issue: When each of the arrays in the secret are processed during node pod startup, host objects are getting created with correct protocol on each of the arrays. But the flags that are used to determine the protocol are saved in the Node's controller service, which is later used during NodeStageVolume and other Node calls. So, depending on whichever array was last processed, that protocol is used for these Node calls. This causes the 'unable to find device' failure.

Fix: Similar to how the FC/NVMe initiators are maintained in the service for each of the arrays as 'map', NVMe and FC protocol flags are maintained in the same way for each of the arrays.

GitHub Issues

List the GitHub issues impacted by this PR:

GitHub Issue #
dell/csm#1539

Checklist:

• I have performed a self-review of my own code to ensure there are no formatting, vetting, linting, or security issues
• I have verified that new and existing unit tests pass locally with my changes
• I have not allowed coverage numbers to degenerate (pkg/node 82.0% to 82.3%)
• I have maintained at least 90% code coverage
• I have commented my code, particularly in hard-to-understand areas
• I have added tests that prove my fix is effective or that my feature works
• Backward compatibility is not broken

How Has This Been Tested?

K8s cluster setup with iSCSI and NVMe pre-req steps. Added 2 arrays in the secret with NVMe/TCP for array-1 and iSCSI for array-2. Host objects are created on both the arrays as expected once node pods are deployed.

Provisioned PV with SC referring to NVMe/array-1. Issue was reproduced.
With the fix, the steps are repeated and it worked.

Provisioning from other array with iSCSI protocol too worked. App pods are in running state and can write data to it.

tests/simple.yaml also passed.

cert-csi suites passed for both NVMe and iSCSI based storage classes.

Logs and reports are attached to ticket 28493.

[root@master-1-SPknwwOOoaVwH my-configs]# k get pv
NAME                   CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM          STORAGECLASS         VOLUMEATTRIBUTESCLASS   REASON   AGE
csivol-sl-5b1ed06362   11Gi       RWO            Delete           Bound    nsps2/pvcps2   powerstore-iscsi     <unset>                          2m20s
csivol-sl-aba3a6f497   9Gi        RWO            Delete           Bound    nsps1/pvcps1   powerstore-nvmetcp   <unset>                          50m
[root@master-1-SPknwwOOoaVwH my-configs]#
[root@master-1-SPknwwOOoaVwH my-configs]#
[root@master-1-SPknwwOOoaVwH my-configs]# k get pvc -A
NAMESPACE   NAME     STATUS   VOLUME                 CAPACITY   ACCESS MODES   STORAGECLASS         VOLUMEATTRIBUTESCLASS   AGE
nsps1       pvcps1   Bound    csivol-sl-aba3a6f497   9Gi        RWO            powerstore-nvmetcp   <unset>                 50m
nsps2       pvcps2   Bound    csivol-sl-5b1ed06362   11Gi       RWO            powerstore-iscsi     <unset>                 2m24s
[root@master-1-SPknwwOOoaVwH my-configs]#
[root@master-1-SPknwwOOoaVwH my-configs]#
[root@master-1-SPknwwOOoaVwH my-configs]# k get pods -A | grep nsps
nsps1                         powerstoretest-0                                        1/1     Running   0             51m
nsps2                         powerstoretest-0                                        1/1     Running   0             2m32s
[root@master-1-SPknwwOOoaVwH my-configs]#