csi: unpublish workflow ID mismatches

[tgross]

Fixes for #7628

• The CSI plugins uses the external volume ID for all operations, but the Client CSI RPCs uses the Nomad volume ID (human-friendly) for the mount paths. Pass the External ID as an arg in the RPC call so that the unpublish workflows have it without calling back to the server to find the external ID.
• The controller CSI plugins need the CSI node ID (or in other words, the storage provider's view of node ID like the EC2 instance ID), not the Nomad node ID, to determine how to detach the external volume.

[tgross]

I want to do some refactoring after the release with some of these names to disambiguate them to prevent this sort of error in the future, but for now this will do the job.

[langmartin]

It seems like this failure could be temporary, will we retry this again if the node plugin is in the process of coming back up? Also, is the node CSI id constant when the plugin comes back up or is it generated by the node plugin everytime it starts?

[tgross]

The GC job will get requeued (which works fine for us with #7632 where the Job.Deregister will use the same GC path).

And as far as I can tell the CSI Node ID is implementation-specific. But in practice it has to be a fixed identifier of the underlying host. So for example, in the EBS case it's the EC2 instance ID, because if it wasn't the controller wouldn't be able to attach the external volume to it.

[tgross]

#7632 includes all these changes, so we can either merge that in to pick these all up or merge this separately and rebase it from master once that's done.

[tgross]

Closing as these changes were rolled into #7632

[github-actions]

I'm going to lock this pull request because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.