verify hostname renaming of the node hosting a cstor pool does not result in data loss

e2e Test: User wants to delete a node by moving the cStor pool (disks) to a new node. ( Same as rename the hostname of the Node on which a cStor Pool is created).
Process do to this with SPC.
=> cStor Pool (using SPC) is created with Block Devices
=> If Block Devices are virtual devices, block device uuid is dependendent on the hostname. After rename, NDM creates a new BD.
=> CSP will be in pending state = because of node selector and also the older BD name.
=> Manual intervention is required by the user to fix this issue.
Issues with Manual Process:
=> Editing the SPC, and replacing old BD with new BD - will trigger delete of old CSP and creation of new CSP (data loss)
=> (This has been avoided for SPC by putting a check to not delete a CSP if data/volumes exists on it)
=> (With CSPC, blanket list of devices is not available to make mistakes)
=> (With NDM (currently in alpha), there is a check to create unique uuid for virtual devices as well, that removes the dependency on hostname)
=> The user seemed to requested for support and followed the steps outlined in:

• https://github.com/openebs/openebs-docs/blob/day_2_ops/docs/cstor_add_disks_to_spc.md
• https://docs.openebs.io/docs/next/ugcstor.html#scaling-up-of-cvr
• https://docs.openebs.io/docs/next/ugcstor.html#scaling-down-of-cstor-volume-replica
  => When the user requested for information - Doing cleaning and removing nodes, we should anticipate what they want to do and validate the steps before sending.
  => (Resolution: With CSPC (currently in alpha), this feature needs to be automated.)

Review the SPC disk-management steps in the linked cstor_add_disks_to_spc.md and cStor scaling documentation, then inspect the repository's existing e2e test entry points. Define a test for renaming the host node of a cStor pool and verify that the pool and its data remain available without manual replacement of block devices.