* Fix `rustix::fs::Dir` to avoid unbounded buffer growth.

Fix `Dir`'s buffer size computation to avoid resizing past a fixed
upper limit. This prevents it from growing without bound, such as in
the case of `Dir::rewind` for repeated iterations with the same `Dir`.

* Don't let `Dir` continue to try to iterate after a failure.

* Handle `io::Errno::INTR` gracefully.

* Write a more detailed comment on the buffer growth policy.

* Also mention that no buffer can ever be big enough for everything.

* Add tests against over-allocation & stuck iterator

* Rm `dir_iterator_does_not_overallocate` unit test in favour of docs

* Extend `test_dir` to cover `rewind`.

* Consistently handle directory removal as ending the stream.

libc implementations of directory iteration handle directory removal
by just ending the stream. In the linux_raw backend, this looks like
`ENOENT` from `getdents64`, so change the code to check for `ENOENT`
and end the stream.

This requires changing the `dir_iterator_does_not_get_stuck_on_io_error`
test to no longer expect a failure, so it's now renamed to
`dir_iterator_handles_dir_removal`.

To test the error case, add a new `dir_iterator_handles_io_errors`
test which uses `dup2` to induce an error, in both the linux_raw and
libc backends.

This exposes the fact that the libc `Dir` implementation was also
assuming that users would stop iterating after hitting a failure, so
add a `any_errors` flag to the libc backend as well.

* Add a test for removing the directory after doing `read_from`.

* In the libc backend, handle `ENOENT` when opening ".".

---------

Co-authored-by: cyqsimon <28627918+cyqsimon@users.noreply.github.com>

* Disable MIPS in CI.

Enable check-only testing.

* Unpin nightly.

* Disable MIPS check tests too.

* Mention `rusl` as another similar crate.

* Fix a test on illumos.

/dev/stdin may be inaccessible in some sandboxed configurations, so just
gracefully return if opening it fails.

The tests currently fail with link errors:

/usr/lib/gcc-cross/riscv64-linux-gnu/9/../../../../riscv64-linux-gnu/bin/ld: -march=rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0: unsupported ISA subset `z'
          /usr/lib/gcc-cross/riscv64-linux-gnu/9/../../../../riscv64-linux-gnu/bin/ld: failed to merge target specific data of file /home/runner/work/rustix/rustix/target/riscv64gc-unknown-linux-gnu/release/deps/rustix-de11d1cc9b23d8e9.rustix.57e81a24c389c933-cgu.1.rcgu.o

…896) (#898)

Unlike with `p{read,write}`, Linux's `p{read,write}v` syscall's offset
argument is not passed in an endian-specific order. And, the expectation is
for syscall wrappers to always pass both the high and low halves of the
offset as separate arguments, even though on 64-bit architectures the low
half is passed throgh as a 64-bit value containing the full offset and the
kernel doesn't mask it.

And `p{read,write}v2` follow the behavior of `p{read,write}`.