output: support version ID

[pmrowla]

• ❗ I have followed the Contributing to DVC checklist.

• 📖 If this PR requires documentation updates, I have created a separate PR (or issue, at least) in dvc.org and linked it here.

Thank you for the contribution - we'll try to review it as soon as possible. 🙏

related to #8164

This PR does not address import behavior. When using dvc import-url azure://container/file?versionid=1234, the pre-existing behavior will still occur, so the resulting import will be permanently pinned to azure://container/file?versionid=1234. dvc update will not check for a new version of azure://container/file.

The only import related change is that the version_id will be captured in the .dvc file like:

md5: b332f7591398ef3d5e32c97f2ff689f9
frozen: true
deps:
- etag: '0x8DA79D118EC7839'
  size: 2
  version_id: '2022-08-09T06:33:06.7654238Z'
  path: azure://test-container/dir/file?versionid=2022-08-09T06:33:06.7654238Z
outs:
- md5: 6654c734ccab8f440ff0825eb443dc7f
  size: 2
  path: file

(whereas the old .dvc file would just contain path: azure://container/dir/file?versionid=2022-08-09T06:33:06.7654238Z and no version_id field)

[pmrowla]

currently unused but will be needed for updating imports

[pmrowla]

After discussion with @efiop we concluded that

• explicitly versioned paths should stay explicitly versioned paths
• explicitly unversioned paths should stay unversioned
• output.fs_path will contain whatever path the user gave us
• we should treat captured version IDs purely as metadata (and should never be merging path+version_id in Output behavior)

---

This means that these two cases in a .dvc file are not the same thing:

path: s3://bucket/foo
version_id: 1234

path: s3://bucket/foo?versionid=1234
version_id: 1234

In the first case, I am tracking the explicit path s3://bucket/foo, and at the time I tracked it the version ID was 1234. changed_meta() will return True if the file is ever updated on S3, since S3 will then return a new "latest version ID" for foo.

For calls like out.exists() we would end up checking that foo still exists in the bucket. We would not be checking to see whether or not version 1234 of foo still exists. So in the event that a user deleted foo (but did not purge old versions), out.exists() will return False.

In the second case, I am tracking the explicit path s3://bucket/foo?versionid=1234. changed_meta() should never return True for this case, since I am tracking an explicitly version-pinned file (foo?versionid=1234).

For calls like out.exists() we would check that the specific version 1234 still exists in the bucket. If that version has been purged, out.exists() would return False, even a current version of foo is still present in the bucket.

@dberenbaum this seems like something which will not be obvious to users at all but we will eventually have to document/explain it, please take a look and make sure you're on the same page for now

[efiop]

Thank you @pmrowla ! 🙏