nproc: replace num_cpus crate with thread::available_parallelism

[souzaguilhermea]

Closes #4351

[sylvestre]

Looks good
Should we check the error ?
(in which cases can we get any?)

[souzaguilhermea]

From what i have read here thread::available_parallelism a error will, but it's not limited to, return in the following cases:

• If the amount of parallelism is not known for the target platform.
• If the program lacks permission to query the amount of parallelism made available to it.

I'm not sure if at any point we will reach those scenarios, but I'm doing a research to see others pitfall we may find.

[tertsdiepraam]

I think GNU nproc just returns 1 processor if all methods fail: https://github.com/coreutils/gnulib/blob/f2b8ad906cbc861552a64e3804e5851c323cbac7/lib/nproc.c#L339

Not sure I agree with that, but that's probably what we should do for compatibility.

[sylvestre]

one of the great thing about Rust. it forces us to have conversations about the right error handling :)

[souzaguilhermea]

So for compatibility reasons it's better to return 1 in case it falls in an error?

If we agree with that I will do the changes.

[tertsdiepraam]

Yes I think so, but let's also include a comment on the GNU behaviour for context.

[github-actions]

GNU testsuite comparison:

Congrats! The gnu test tests/tail-2/inotify-dir-recreate is no longer failing!

[github-actions]

GNU testsuite comparison:

Congrats! The gnu test tests/tail-2/inotify-dir-recreate is no longer failing!

[tertsdiepraam]

Looks good! Just one more nit

[github-actions]

GNU testsuite comparison:

GNU test failed: tests/tail-2/inotify-dir-recreate. tests/tail-2/inotify-dir-recreate is passing on 'main'. Maybe you have to rebase?

[tertsdiepraam]

All good now! Thanks! For future PRs, could you squash the commits a bit more? I squashed them all while merging now.

[souzaguilhermea]

Of course, I'll pay more attention in the next PRs and sorry for the inconvenience.

[sylvestre]

not a big deal :) it is just best practice :)