Modify ControllerModifyVolume to support KEP-5381

[iltyty]

What type of PR is this?
Feature

What this PR does / why we need it:
This PR adds new fields to ControllerModifyVolumeRequest and ControllerModifyVolumeResponse to support KEP #5381.

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:
This is an alternative for PR #593.

Does this PR introduce an API-breaking change?:

none

[saad-ali]

Can you specify the specific use cases that we are trying to solve here? And what are the use cases that are explicitly not supported?

[iltyty]

Can you specify the specific use cases that we are trying to solve here? And what are the use cases that are explicitly not supported?

We've already mentioned this in KEP 5381, please refer to here: kubernetes/enhancements#5382.

[gnufied]

I think adding more capability (or features) to existing ControllerModifyVolume should be avoided. ControllerModifyVolume could become swiss-army RPC (it already partially is) of all CSI rpc calls.

SP A uses it to apply, iops and throughput, SP B uses it to apply tags to volumes, SP C - uses it to apply iops, througput and now change topology. SP C - could use it for all the above and in stages.

The problem is, when a RPC call does too many things - it is very easy to get implementation wrong. It is very hard for CO to reason about, whether the operation has succeeded or failed. It also opens room for partial application of one or more properties which is undesirable, in case user wants CO to cancel previously issued operation (or at least stop trying).

While CSI RPC calls are not atomic, it is better if they do one thing and one thing only. It is better if CO knows what they are doing and has explicit state to track the operation (because drivers are supposed to be stateless).

[bswartz]

We have agreed not to allow topology modifications in the ControllerModifyVolume RPC, which makes this PR obsolete.