Implement Chain with Option fuses

[cuviper]

The iterators are now "fused" with Option so we don't need separate state to track which part is already exhausted, and we may also get niche layout for None. We don't use the real Fuse adapter because its specialization for FusedIterator unconditionally descends into the iterator, and that could be expensive to keep revisiting stuff like nested chains. It also hurts compiler performance to add more iterator layers to Chain.

This change was inspired by the proposal on the internals forum. This is an alternate to #70332, directly employing some of the same Fuse optimizations as #70366 and #70750.

r? @scottmcm

[cuviper]

@bors try @rust-timer queue

Locally, I measure this being a little faster than nightly on deeply-nested-opt, but a little slower on deeply-nested-debug, which is probably OK. It also doesn't suffer from #70749.

@KrishnaSannasi I went ahead and tried your folding idea for nth too, but that added ~40% instruction count to deeply-nested-opt. We might still justify that if it helps the runtime performance of Chain::nth with internal iteration, but I'll let you explore that separately.

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit 859b8da with merge 1f6bcab4a99b6f10ce766a1fe581010d3dd68f6a...

[bors]

☀️ Try build successful - checks-azure
Build commit: 1f6bcab4a99b6f10ce766a1fe581010d3dd68f6a (1f6bcab4a99b6f10ce766a1fe581010d3dd68f6a)

[rust-timer]

Queued 1f6bcab4a99b6f10ce766a1fe581010d3dd68f6a with parent 42abbd8, future comparison URL.

[rust-timer]

Finished benchmarking try commit 1f6bcab4a99b6f10ce766a1fe581010d3dd68f6a, comparison URL.

[cuviper]

@scottmcm I updated count and last as you suggested -- locally it didn't seem to make much difference, for better or worse. I tried size_hint too, since that's a similar pattern, but that regressed performance quite a bit, so I dropped it. Perhaps you were wise not to ask for that one. 🙂

[cuviper]

That perf report matches my own results -- better on deeply-nested-opt, worse on deeply-nested-debug, and slight improvement / neutral on the rest.

We can also compare to #70332, with the caveat that they're not on the exact same merge base, but this PR looks a lot better.

[scottmcm]

@bors r+

Perhaps you were wise not to ask for that one. 🙂

I almost did 🙂 But then I thought about it more and worried that the saturating_add is more scary to be doing every time than the wraps-in-release add in count, for example.

[bors]

📌 Commit ce8abc6 has been approved by scottmcm

[pnkfelix]

This seems like it injected regression noted in issue #71359.

The regression in question might be fairly niche.

But I still wanted to check in about whether the benefit from this PR is significant enough to justify the risk associated with issue #71359?

cc @cuviper and @scottmcm

[cuviper]

IMO that's niche enough to not worry about -- they were using a very long chain, but even that is now resolved by bodil/typed-html#117 (though not published yet). Plus, that project is already rife with increased recursion_limit, as high as 1024 in one example.

Also, this PR had an incidental benefit on the very long compilation time in #70749 -- that code now compiles quickly with the Option-based Chain.