Drop hashsum in favor of standalone binaries

[RenjiSann]

This PR drops the hashsum binary, that was the way for uutils to implement standalone checksum algorithms, to introduce specific binaries.

I chose to regroup all the common CLI handling into a cli submodule under the uucore::checksum feature, that's debatable, as it introduces a clap dependency in uucore, which.

Another way I can see it would be to replicate the way base32, base64 and basenc work, where all the common implementation lives under base32, and the other utils depend from it, but I'm not really convinced with this.

Let's discuss it !

[oech3]

Do you want to avoid ln -s cksum md5sum (and dropping ln -s coreutils md5sum)?

[github-actions]

GNU testsuite comparison:

GNU test failed: tests/tty/tty-eof. tests/tty/tty-eof is passing on 'main'. Maybe you have to rebase?

[codspeed-hq]

CodSpeed Performance Report

Merging #9776 will degrade performance by 16.55%

_{Comparing RenjiSann:checksum-common-cli (1a19a39) with main (2d718f2)}

Summary

❌ 13 regressions
✅ 114 untouched
⏩ 6 skipped¹

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	BASE	HEAD	Efficiency
❌	wc_bytes_synthetic[500]	185.5 µs	208.3 µs	-10.94%
❌	cksum_blake3	208.9 µs	249.8 µs	-16.35%
❌	sort_ascii_c_locale	21.5 ms	22.6 ms	-4.73%
❌	b64_decode_ignore_garbage_synthetic	163.5 µs	184.7 µs	-11.44%
❌	b64_decode_synthetic	166.6 µs	188.4 µs	-11.57%
❌	b64_encode_synthetic	162 µs	184.3 µs	-12.09%
❌	split_number_chunks	294.7 µs	315.8 µs	-6.69%
❌	split_bytes	509.6 µs	528.6 µs	-3.6%
❌	factor_multiple_u64s[2]	211.7 ms	253.7 ms	-16.55%
❌	cp_large_file[16]	362.9 µs	384.8 µs	-5.68%
❌	rm_single_file	119.1 ms	134.7 ms	-11.59%
❌	mv_force_overwrite	144.1 ms	160 ms	-9.96%
❌	mv_single_file	135.3 ms	159.9 ms	-15.35%

Footnotes

1. 6 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[RenjiSann]

Do you want to avoid ln -s cksum md5sum (and dropping ln -s coreutils md5sum)?

No, in my mind, we have separate binaries for cksum, b2sum, md5sum, etc...
That being said, I thought about having a single directory in src/uu, with a single main file which we could make several binaries from it (and its behavior would change depending on its name, but that would play poorly with our current testing system)

[oech3]

Why b2sum only? Just forgot other bins?

[RenjiSann]

No no, it's the reason it's still in draft

[oech3]

hasusum.rs is still remain. But we remove it later and totail size of source code is reduced. Right?

[oech3]

We have

coreutils/util/build-gnu.sh

Lines 96 to 101 in 0fbc17c

	# Create *sum binaries
	for sum in b2sum md5sum sha1sum sha224sum sha256sum sha384sum sha512sum; do
	sum_path="${UU_BUILD_DIR}/${sum}"
	test -f "${sum_path}" || (cd ${UU_BUILD_DIR} && ln -s "hashsum" "${sum}")
	done
	test -f "${UU_BUILD_DIR}/[" || (cd ${UU_BUILD_DIR} && ln -s "test" "[")

too.
(I have a PR to use coreutils for faster CI at GnuTests to remove it, but not merged.)

[github-actions]

GNU testsuite comparison:

GNU test failed: tests/tty/tty-eof. tests/tty/tty-eof is passing on 'main'. Maybe you have to rebase?
Congrats! The gnu test tests/tail/inotify-dir-recreate is now passing!

[github-actions]

GNU testsuite comparison:

Skipping an intermittent issue tests/misc/tee (passes in this run but fails in the 'main' branch)

[oech3]

Is this .png needed (instead of symlink to logo)?

[oech3]

#9797 OK before this?

[oech3]

I think 6 PR (each bins) for this is OK.

[RenjiSann]

Closing this as I'm finally going with the base32 like approach, which IMO is better since it keeps argument handling from uucore, and also, to some extent, it avoids flooding uucore fluent files with checksum-cli specific stuff