Feature request: Draft crates and versions

[hvenev-insait]

My understanding of the deletion policy is that it only applies to whole crates and not to individual versions. For any crate that has had any version available for longer than 3 days, or for which there are dependencies for any version, no version can be deleted.

Even if one version of a crate was uploaded correctly, this does not mean that mistakes will never happen in the future. Therefore I think it should be possible for new uploads to new or existing crates to have a "draft" status.

A draft version is somewhat similar to a yanked version, with the primary differences being that:

• A draft version can be deleted at any time.
• Once a version is marked as non-draft, it cannot be marked as draft.

In order to facilitate easier testing of draft versions, as well as the publishing of non-trivial dependency chains:

• In the manifest the use of draft versions may be explicitly permitted:

[dependencies]
foo = { version = "0.1.0", draft = true }

• When a .crate tarball is created, draft = true is removed from all dependency specifications in Cargo.toml. However, Cargo.lock may still refer to draft versions.
• A version can only be marked as non-draft if all of its dependencies (in Cargo.lock) exist and are non-draft.

This can also be integrated with API token permissions:

• A new API token permission, publish-draft, permits the creation of draft versions of new and existing crates. It does not permit marking versions as non-draft.
• The publish-new and publish-update permissions are required to mark versions as non-draft.

Finally, in order to avoid the creation of a "draft-only" ecosystem,

• If a version has been marked as draft for 30 days, it is automatically deleted.