Support Velero plugin versioning

[nrb]

Describe the problem/challenge you have
Right now, when Velero makes changes to its plugin APIs, there's no mechanism for the Velero server to communicate the version of the API that is supported, or for the plugins to communicate what version they implement.

This leads to restrictions on what can be changed in the API, or breaking everyone's code with major releases. Backwards-compatible changes either lead to API expansion, or implementations that have to check for the presence of specific functions, which is a runtime check and prone to error.

Describe the solution you'd like
Ideally, there would be a version negotiation system that allows Velero's server to support some level of version skew, decoupling Velero and plugins from having to move their API in lock step. This way, Velero core can support some number of API versions while iterating on new API features, and plugin authors are not forced to upgrade right away.

The go-plugin library we use has support for this, but I don't know how sophisticated their implementation is.

Anything else you would like to add:
#1303 updated go-plugin to a version that supported plugin version negotiation, but I think there's still work to be done on top of that.

Vote on this issue!

This is an invitation to the Velero community to vote on issues, you can see the project's top voted issues listed here.
Use the "reaction smiley face" up to the right of this comment to vote.

• 👍 for "The project would be better with this feature added"
• 👎 for "This feature will not enhance the project in a meaningful way"

[nrb]

@phuongatemc I know you're interested in this, and @sseago has some work that would greatly benefit from having this in place.

[reasonerjt]

I'll double check the PRs and associate with this issue.

[reasonerjt]

The versioning mechanism has been provided via #4943
The incremental changes like providing BIA v2 will be tracked via other issues.