Fix random errors for piped input on macos

[Joining7943]

Fix the random errors around piped input, mainly on macos but in theory also possible on other unix systems. When we canonicalize a path to find out if we can treat input from Stdin as fifo (we get a resulting path here) or pipe, (we don't) then it may happen sometimes that the canonicalized path points to /dev/fd/0. We should treat this result like a pipe.

A different solution also may have been to remove the guards from the is_tailable() method, but I've found putting the solution into the resolve() method being more explicit. The is_tailable() method should be refactored anyways also because of @niyaznigmatullin comment here #3919 (comment)

Fixes #3958, #3916

[niyaznigmatullin]

I hope you've seen my thoughts on the errors: #3895 (comment)

[Joining7943]

Thanks for pointing this out. I haven't seen your comment. But you may have noticed that the code for tail changed quiet a bit since #3905. I'm in the process of writing an explanation for this fix. It addresses another kind of error than the one you've figured out in #3895. I've removed ignore_stdin_write_error() from the pipe tests, to see if the CI is still failing and it isn't. Let's see how long it lasts and what happens. We can easily revert the deletion of ignore_stdin_write_error() as soon as the random errors around 0 input 0 output reappear.

[niyaznigmatullin]

I suggest you to try to test locally with timeout between spawning child process and writing to stdin, to see when ignoring is for sure required.

[Joining7943]

@niyaznigmatullin The broken pipe errors don't have anything to do with this fix. Can you please stay out :)

[niyaznigmatullin]

Sorry for that. I didn't try to say it's about the change. The suggestion was as an alternative to:

We can easily revert the deletion of ignore_stdin_write_error() as soon as the random errors around 0 input 0 output reappear.

[Joining7943]

No, this is a different kind of beast.

[sylvestre]

let's try to see if it improves the situation