Switch to rustwide for sandboxing

[pietroalbini]

This PR replaces the whole sandboxing and build system with rustwide (Crater's build system extracted into a library). The practical effects of this are:

• The build environment will be the same as Crater.
• Docker is used instead of LXC to sandbox the builds.
• Nightlies are updated every day automatically.
• There is less reliance on Cargo as a library.

Because this will change the sandbox some crates will be broken. I'll write a post for blog.rust-lang.org explaining the changes in the next few days.

This is ready for review, but there are things that needs to be done before this can be deployed:

• Switch this PR to use a crates.io release of rustwide: at the moment this is pointing to the git repository directly, and I want to cut a 0.3.0 release just before this is ready to land.
• Align the rustwide build environment with the current chroot
• Write a blog post explaining the sandboxing changes "Upcoming docs.rs changes" blog.rust-lang.org#403

r? @QuietMisdreavus
cc @Mark-Simulacrum @onur

[pietroalbini]

It should be possible to review this commit-by-commit.

[Mark-Simulacrum]

Didn't review in super great detail but looks good overall. Left some comments.

[Mark-Simulacrum]

I would like to also not have a "number of lines" limit since that seems needless, we have a limit on how many bytes you're emitting which is all we should care about presumably?

[pietroalbini]

I would like to also not have a "number of lines" limit since that seems needless, we have a limit on how many bytes you're emitting which is all we should care about presumably?

Already removed it.

[Mark-Simulacrum]

Networking looks good now.

[pietroalbini]

Addressed all of Mark's review comments.

[pietroalbini]

Updated the rustwide's build environment with the list of crates installed in the current container and wrote a draft of the blog post announcing the changes.

[pietroalbini]

Also created #409 to properly alert docs.rs users of the changes in this PR.

[QuietMisdreavus]

A couple comments from reading over it yesterday. Still reading through everything.

[QuietMisdreavus]

I'm glad these are much more easily found within the file, but i still feel like we should get rustdoc to report these itself if we're going to be automatically updating the compiler. We've had issues where docs.rs hadn't seen a new "essential file" and started posting broken docs until we manually uploaded it. (IIRC, there are still docs that don't have the right settings.js file because we went a long time without saving that...)

[Mark-Simulacrum]

I continue to believe this is not that necessary for this to land; this is a good issue to file for something we need to do, but we've not added such a file in a relatively long time to rustdoc and we can add a comment to rustdoc saying "go ping docs.rs folks if you add a file here".

[Mark-Simulacrum]

But if this is a blocker, then let's lock down nightly for now -- getting rustdoc to print these out seems sort of 'spec' work to me which is always hard :)

[QuietMisdreavus]

I feel like we can get away with landing this without making rustdoc report them, but i would like to have some kind of process so we can quickly update docs.rs if/when new files are added. Making it automatic would be ideal, but in lieu of that, i believe your suggestion of adding a comment to the spot in rustdoc where the static files are emitted should be fine as a stopgap solution.

[pietroalbini]

Yeah, I don't think it's worth blocking on this. Another solution in the meantime is to configure highfive to ping people when that file is changed.

[QuietMisdreavus]

This gets a +1 from me. We've talked about the specifics on Discord already, and i feel like setting these limits for crates will begin to enforce good packaging practices (and possibly put some urgency to get performance work done on rustdoc itself!). This should be good to deploy on Monday, per the recent announcement post.

[pietroalbini]

Ok, merging this 🎉