Add newly-published crates to restricted tokens

[alexcrichton]

I was recently considering trying to use restricted tokens for CI on a repository but ended up deciding not to. One of the issues with tokens that are restricted to a fixed set of crates is that I can't necessarily predict all future crates that the token is going to publish. For example when managing a workspace I'd like CI automation to publish all the crates but the set of crates will grow and/or change over time. Some projects have predictably-named crates so the *-based restrictions work well, but the project that I was working with was the wasm-tools repository which has a set of crates that don't follow any particular naming pattern.

To help manage this a setting I'd find useful to have would be something along the lines of:

• At token creation time, I can add restrictions that match the current set of crates, for example make an explicit list of all crates.
• Next I'd like any newly published crate with this token to be automatically added to the set of crates.

That way the token would be allowed to publish any new crate, but only updates could be posted to initially allowed crates or historically created crates. This mode of tracking would match the workflow well of at least wasm-tools and might work for other workspace-based repositories perhaps.

[walterhpearce]

This sounds like a reasonably good idea and approach to me. Something akin to a "self only" token restriction, essentially creating an isolated user-like scope under a token. It's a sane step without fully having to support other auth sources, while having a GitHub account for CI is cumbersome.

I'd be wary of this being leaned on and expanded though. I can see this quickly evolving into not-users-but-users on crates.io with some feature creep, which we would want to avoid and fully consider an evolution towards.