Migrate jobserver-error run-make test to rmake

[Oneirical]

Part of #121876 and the associated Google Summer of Code project.

In a similar fashion to #128460, this test contains peculiar interactions with the /dev/ directory and piping to file descriptors. Note the massive commented section, which requires figuring out how to pipe /dev/null/ to file descriptor 3 to get this to work.

Will need try jobs, but not yet.

[rustbot]

r? @jieyouxu

rustbot has assigned @jieyouxu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

This PR modifies tests/run-make/. If this PR is trying to port a Makefile
run-make test to use rmake.rs, please update the
run-make port tracking issue
so we can track our progress. You can either modify the tracking issue
directly, or you can comment on the tracking issue and link this PR.

cc @jieyouxu

The run-make-support library was changed

cc @jieyouxu

[bors]

☔ The latest upstream changes (presumably #131917) made this pull request unmergeable. Please resolve the merge conflicts.

[jieyouxu]

FWIW, we might actually just delete the disabled part of this test cc #110321.

The problem is that the jobserver helper thread launched here gets starved out and doesn't run, while the coordinator thread continually processes work using the implicit jobserver token, never yielding long enough for the jobserver helper to do its work (and process the error).

Honestly, I'm not sure this is really worth fixing. It would be nice to have a test to validate the jobserver behavior, but I'm not sure it is worth the expense of changing the coordinator's behavior in some way (since there could be performance losses, for example if it explicitly yielded or waited for the jobserver helper, or more aggressively tried to acquire tokens). I'm not familiar enough with Linux thread scheduling to know why the thread could get blocked for so long, or if there are different approaches to fix the scheduling.

Another thought I just had would be to change the test to generate a binary with enough code to split across a very large number of CGUs (and use -C codegen-units=…). That would ensure that the coordinator does a lot of work, giving it more opportunity to yield. Again, I'm not too familiar with Linux thread scheduling, so I don't know if that would help, but might be worth a shot.

[jieyouxu]

Thanks for the PR, this is superseded by #135461 (with attribution to both authors).