Prevously the `read_to_end` implementation for `std::io::Take` used its
own `limit` as a cap on the `reservation_size`. However, that could
still result in an over-allocation like this:

1. Call `reader.take(5).read_to_end(&mut vec)`.
2. `read_to_end_with_reservation` reserves 5 bytes and calls `read`.
3. `read` writes 5 bytes.
4. `read_to_end_with_reservation` reserves 5 bytes and calls `read`.
5. `read` writes 0 bytes.
6. The read loop ends with `vec` having length 5 and capacity 10.

The reservation of 5 bytes was correct for the read at step 2 but
unnecessary for the read at step 4. By that second read, `Take::limit`
is 0, but the `read_to_end_with_reservation` loop is still using the
same `reservation_size` it started with.

Solve this by having `read_to_end_with_reservation` take a closure,
which lets it get a fresh `reservation_size` for each read. This is an
implementation detail which doesn't affect any public API.

This patch supports less behavior than before, since specifiying stage 1
vs stage 2 is no longer possible, but that is presumably a somewhat rare
use case anyway, so not supporting it seems acceptable (and it can be
readded easily if desired).

In sys/unix/process, we work around the sigemptyset linking issues
on android in two different ways. This change consolidates these
workarounds, and avoids duplicating bindings from `libc`.

It was accidentally removed in a rebase of rust-lang#62727

Fixes rust-lang#63729

This commit backs out rust-lang#46539 in order to fully leverage rust-lang#63579 where
`git` should be able to merge `Cargo.lock` nowadays with only minimal
conflicts.

…kler

avoid unnecessary reservations in std::io::Take::read_to_end

Prevously the `read_to_end` implementation for `std::io::Take` used its
own `limit` as a cap on the `reservation_size`. However, that could
still result in an over-allocation like this:

1. Call `reader.take(5).read_to_end(&mut vec)`.
2. `read_to_end_with_reservation` reserves 5 bytes and calls `read`.
3. `read` writes 5 bytes.
4. `read_to_end_with_reservation` reserves 5 bytes and calls `read`.
5. `read` writes 0 bytes.
6. The read loop ends with `vec` having length 5 and capacity 10.

The reservation of 5 bytes was correct for the read at step 2 but
unnecessary for the read at step 4. By that second read, `Take::limit`
is 0, but the `read_to_end_with_reservation` loop is still using the
same `reservation_size` it started with.

Solve this by having `read_to_end_with_reservation` take a closure,
which lets it get a fresh `reservation_size` for each read. This is an
implementation detail which doesn't affect any public API.

…unksexactmut, r=scottmcm

Implement `nth_back` for ChunksExactMut

This is a part of rust-lang#54054.

r? @scottmcm

…ttmcm

Fix bug in iter::Chain::size_hint

`Chain::size_hint` currently ignores `self.state`, which means that the size hints of the underlying iterators are always combined regardless of the iteration state. This, of course, should only happen when the state is `ChainState::Both`.

…, r=alexcrichton

Don't use stage naming in RUSTFLAGS environment variables

This patch supports less behavior than before, since specifiying stage 1
vs stage 2 is no longer possible, but that is presumably a somewhat rare
use case anyway, so not supporting it seems acceptable (and it can be
readded easily if desired).

Fixes rust-lang#33609

Consolidate sigemptyset workarounds

In sys/unix/process, we work around the sigemptyset linking issues
on android in two different ways. This change consolidates these
workarounds, and avoids duplicating bindings from `libc`.

Restore the rustc_plugin crate in the sysroot

It was accidentally removed in a rebase of rust-lang#62727

Fixes rust-lang#63729 (rls build failure)

…rk-Simulacrum

Allow git to merge `Cargo.lock`

This commit backs out rust-lang#46539 in order to fully leverage rust-lang#63579 where
`git` should be able to merge `Cargo.lock` nowadays with only minimal
conflicts.