cat, tail, head:allways splice with broker pipe for throughput

[oech3]

splice without broker is slower by unknown reason (needs pv from main branch)

> target/release/cat /tmp/huge|pv>/dev/null
50.2GiB 0:00:01 [50.2GiB/s] 
> target/release/cat-direct /tmp/huge|pv>/dev/null
38.2GiB 0:00:01 [38.2GiB/s]

Closes #12464 Closes #12465
cc @dragutreis

[github-actions]

GNU testsuite comparison:

Skip an intermittent issue tests/cut/bounded-memory (fails in this run but passes in the 'main' branch)
Note: The gnu test tests/expand/bounded-memory is now being skipped but was previously passing.
Note: The gnu test tests/printf/printf-surprise is now being skipped but was previously passing.

[pixelb]

The more important part of this worth mentioning (as I discussed with you previously) is that an intermediate pipe is required to distinguish input from output errors. Currently cat will flag issues on the output as an error with the input, which could send users down entirely wrong rabbit holes

[oech3]

Yes. But more refactoring is needed to fix it. So it will be fixed at different PR.
But I think pipe does not cause EIO and ENOSPC and they are coming from non-pipe one for the case direct splice. No?

[pixelb]

Yes. But more refactoring is needed to fix it. So it will be fixed at different PR. But I think pipe does not cause EIO and ENOSPC and they are coming from non-pipe one for the case direct splice. No?

Right, but keying on errnos like that is problematic, so the most sensible way is always to have the separated splice(), and it's a nice side affect of not being slower

[oech3]

It is hard to actually cause it. but even we use middler pipe, the middler itself's error cannot be distinguished with in/output.
So I'm still interested in direct splice by that reason (after performance drop was fixed by someway, or started uising io_uring).