Bump rayon from 1.3.0 to 1.4.1

[dependabot]

Bumps rayon from 1.3.0 to 1.4.1.

Changelog

Sourced from rayon's changelog.

Release rayon 1.4.1 (2020-09-29)

• The new flat_map_iter and flatten_iter methods can be used to flatten sequential iterators, which may perform better in cases that don't need the nested parallelism of flat_map and flatten.
• The new par_drain method is a parallel version of the standard drain for collections, removing items while keeping the original capacity. Collections that implement this through ParallelDrainRange support draining items from arbitrary index ranges, while ParallelDrainFull always drains everything.
• The new positions method finds all items that match the given predicate and returns their indices in a new iterator.

Release rayon-core 1.8.1 (2020-09-17)

• Fixed an overflow panic on high-contention workloads, for a counter that was meant to simply wrap. This panic only occurred with debug assertions enabled, and was much more likely on 32-bit targets.

Release rayon 1.4.0 / rayon-core 1.8.0 (2020-08-24)

• Implemented a new thread scheduler, RFC 5, which uses targeted wakeups for new work and for notifications of completed stolen work, reducing wasteful CPU usage in idle threads.
• Implemented IntoParallelIterator for Range<char> and RangeInclusive<char> with the same iteration semantics as Rust 1.45.
• Relaxed the lifetime requirements of the initial scope closure.

Contributors

Thanks to all of the contributors for this release!

• @​CAD97
• @​cuviper
• @​kmaork
• @​nikomatsakis
• @​SuperFluffy

Release rayon 1.3.1 / rayon-core 1.7.1 (2020-06-15)

• Fixed a use-after-free race in calls blocked between two rayon thread pools.
• Collecting to an indexed Vec now drops any partial writes while unwinding, rather than just leaking them. If dropping also panics, Rust will abort.
  • Note: the old leaking behavior is considered safe, just not ideal.
• The new IndexedParallelIterator::step_by() adapts an iterator to step through items by the given count, like Iterator::step_by().
• The new ParallelSlice::par_chunks_exact() and mutable equivalent ParallelSliceMut::par_chunks_exact_mut() ensure that the chunks always have

... (truncated)

Commits

• 5107676 Merge #583
• c90e1ba Release rayon 1.0.2 / rayon-core 1.4.1
• 1eea820 Update rayon-demo dependencies
• 23e7d9b Update rand to 0.5
• b35e9d7 Merge #584
• 2179f45 Fix doc links to avoid warning on nightly
• c2150b1 Merge #578
• 8ba64ab Merge #563
• 800c736 Add generic tests for try_fold
• e2336fe Make it clearer that we're driving some ranges indexed
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[jcape]

@dependabot rebase

[jcape]

We'd previously skipped this because the change from rayon-1.3 -> rayon-1.4 was a new threading model, and it was generally deemed too risky to merge right before our first release. Now that we've just branched for our mobilecoin-1.2 release, there's plenty of time to test this for mobilecoin-1.3, and so this is a good time to bring this in now.

Additionally, this has lived out in the world for 9 extra months, and other projects have used it, so I'm more confident that it's likely to work (and/or 1.5.x works, and/or we can fix it before we need to do another release from master).