Parallelize rustdoc rendering

[camelid]

I and others would like to parallelize rustdoc rendering. It is "embarrassingly parallel" ... except that rustdoc has some technical debt in the form of global mutable state that will have to be dealt with first.

Steps

• Get rid of CURRENT_DEPTH thread-local (rustdoc: Get rid of CURRENT_DEPTH thread-local variable #82742)
• Make Span etc. Send and Sync
• Use RwLock instead of RefCell for SharedContext fields (or make Context, and by extension SharedContext, Send and Sync some other way)
• So many more things...
• Add parallelism via MPSC channels and rayon

cc @rylev @jyn514
cc https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/windows-rs.20perf/near/226957262 (was going to open this issue anyway, but noticed this discussion so thought I'd link to it)

[jyn514]

This is a duplicate of #82294 I think.

[camelid]

Maybe I'll add this issue description to the description of the other one?

[camelid]

I would like to have a check-list of things to do before we can parallelize.

[jyn514]

Personally I think because this is blocked on parallel_compiler it's not worth spending too much time on (note that TyCtxt is not thread-safe without cfg(parallel_compiler)). parallel_compiler is on the backburner for T-compiler and AFAIK will be for a quite a while.

[camelid]

Okay, that makes sense 👍

[the8472]

Add parallelism via MPSC channels and rayon

jobserver and/or -j N parameter will be needed too to obey parallelism limits of cargo and bootstrap.

[jyn514]

jobserver and/or -j N parameter will be needed too to obey parallelism limits of cargo and bootstrap.

@the8472 hmm, I'm not sure -j makes sense in this context - normally -j is intended for cpu-bound tasks, like compiling. But this is almost purely IO, so we should be able to potentially have thousands of files being written at once without too much resource contention.