Remove rayon from default features

[197g]

See #2245 for the plan which also includes this as one of the steps.

[fintelia]

I still think that rayon should be a default feature.

The majority of end users are going to use whatever the default settings are, so removing rayon from the default list is going to make things slower for them. Worse, having it disabled-by-default makes it much harder to justify the implementation effort of writing parallel versions of algorithms at all since most users won't benefit from them.

(As a related example, we have the nasm feature to speed up AVIF encoding but I think many folks working with AVIF don't know about that.)

[197g]

I'm actually pretty neutral here but the list in #2245 should match our resolution of this issue. The argument that this is similar to SIMD speedup, where runtime dispatch is the correct approach in my opinion, sounds fine to me. If only rayon had a bit of a better story around configuring the pool / how-to-start-threads / handles to dedicated parts of a pool that guarantee structured concurrency then this would a very, very easy choice for me, too. Also I can't recall hearing about trouble with this for a long time, apart from the threading issues in avif that was actually not rayon. Then again, we effectively gave up using it in jpeg decoding and gained performance in the process /shrug.

[197g]

Oh, regarding the issues we faced in jpeg which made us give up the parallelization: https://github.com/image-rs/canvas/blob/master/matrix-slice/src/lib.rs Safety review outstanding this might be (part of) a solution for distribution a matrix of output pixels to different threads. I'd been teasing the need for this all the way back when we had an ad-hoc unsafe code but did not find anything in the ecosystem which provided a solution to it.. surprisingly.