manual request of a documentation rebuild for crate owners

[syphar]

This is split off from automated rebuilds (#464), specifically https://github.com/rust-lang/docs.rs/issues/464#issuecomment-916265156 by @ShadowJonathan :

One other thing that i'd like to suggest is rebuild requests, to be able to manually request somewhere to rebuild a (very) out of date documentation of a crate. I just encountered this with anymap, and while i think a rebuild of old documentation on every major release, or after a amount of "rotting" time (lets say, longer than a year or two years), and then automatically rebuilding them (most popular crates first), while i think that would be a good approach, the best heuristic would be to be able to have users re-request a build. (and have the button visible and active only when a build is X amount of time old) In a good-faith case, someone clicks this when they see the documentation style outdated, and they think it'd be "good" to have it be up-to-date. In a bad faith case, someone goes around queuing this for every crate. I personally see this as alright, but it depends on how much the build system can handle, and if it's possible to queue this on a very low priority.

[syphar]

General notes from the top of my head:

• we don't want to handle user authentication in docs.rs, so the rebuild would have to be triggered from crates.io,
• probably using a private authenticated API between crates.io & docs.rs
• we would use a lower priority (probably the same as manual rebuilds from the shell, -5)

Either crates.io would do a GET request first to know if a rebuild is possible, and/or we deliver a nice error message why we can't execute a rebuild for a crate.

Because it's triggered through the crates.io interface, "bulk" rebuilds would be limited anyways.

Reasons I can imagine why we would block the rebuild:

• there is already another build queued for that release
• last build(-try) for that releases was less than X hours ago (TBD)
• at some point, perhaps certain build errors where we already know that a rebuild won't help? (might be too complex)
• ?

[Nemo157]

Depending on the expected scale, we could maybe automate this through github actions, have a rebuild request issue type and a script that runs on issue creation and queues the rebuild.