Update documentation in accordance with vSphere Supervisor

[kolluria]

Summary:

This MR updates the documentation to provide clear instructions to deploy CNS Manager on vSphere Supervisor 8.0.

Change List:

1. README is updated with latest information
2. svMotion which is a supported feature for Vanilla k8s clusters is removed from Supervisor as WCP mobility operator can be used for the same.
3. suspend and resume volume provisioning endpoints are removed as they are not supported on Supervisors
4. client-sdk is generated with the latest spec
5. Examples are updated to reflect the latest spec
6. Service type in the deployment is converted to a LoadBalancer from a NodePort
7. Deployment instructions are updated to work accurately with Supervisor

Note: Spec was generated using the following -

curl -X POST \ 
  https://generator3.swagger.io/api/generate \
  -H 'content-type: application/json' \
  -d '{
  "specURL" : "https://raw.githubusercontent.com/kolluria/cloud-native-storage-self-service-manager/refs/heads/update-documentation/deploy/swagger-template.yaml",
  "lang" : "go",
  "type" : "CLIENT",
  "codegenVersion" : "V3"
}' --output sdk.zip

[vdkotkar]

@kolluria Instead of keeping 6 commits, will you rebase and keep 1 commit to keep commit history clean?

[kolluria]

@kolluria Instead of keeping 6 commits, will you rebase and keep 1 commit to keep commit history clean?

@vdkotkar yeah. I will do that before we merge. I was just incrementally making changes.

[AciDCooL]

And here i'm sitting like a dumbass deploying it in a tkc :)

Edit:
Or is the namespace part in this comment meant as a vsphere namespace? and thus a tkc:
CNS manager needs to be deployed in one of the namespaces running on the Supervisor in the vCenter.

The namespace part and the word "on" instead of "in" is trowing me off. But it makes sense that is should be the supervisor since the supervisor has the volume handles for the vSAN part.

Had to reference and delete 144 fcd's by hand today, what a mess this system they implemented. Maybe cool if it works. But if you hit a bug; Like this timeout issue with snapshots in a tkc. Big oof. This is by far the worst experience I ever had with storage.

And if this is the case to deploy on the supervisor then there is allot of info missing for vSphere supervisor. For instance howto install and expose this? Supervisor can only be accessed from a vCenter server to gain the privileged needed. And there is no middleware for a lb normally. Not even sure this will work from a network perspective if nsx is involved.
Than should it be a vsphere supervisor service? And hopefully not as a vsphere pod since since that in turn will not work with vds backed networks when using nsx. Ohh how this has become a total disaster. Ill stick with my primitive govc commands for now and hopefully we'll resolve the snapshot bug soon.