split: implement undocumented option ---io-blksize

[jfinkels]

GNU split has an undocumented command-line option ---io-blksize (note three dashes, not two). For example:

$ split ---io-blksize=1 infile

I don't know what the option does, but the GNU test suite uses this option in some places so we'll need to at least accept it in order for the test suite to pass.

[tertsdiepraam]

See this comment for how to implement an option with 3 leading dashes in clap 3: #2907 (comment)

[ghost]

I spent sometime analysing the ---io-blksize option in GNU Coreutils. The input is populated to a field in_blk_size which is then used as buffer size while reading file in certain scenarios. I need some inputs on below to determine what should be done for Rust coreutils.

1. I see the input value is capped at MIN(IDX_MAX, SIZE_MAX) - 1. I don't know what IDX_MAX is. Anyone has any idea?
   https://github.com/coreutils/coreutils/blob/9a29ee2903df183f904cfd61f17e743ad9d2180b/src/split.c#L1508
   in_blk_size = xdectoumax (optarg, 1, MIN (IDX_MAX, SIZE_MAX) - 1, multipliers, _("invalid IO block size"), 0);

2. If the input parameter is not provided, the default value of in_blk_size is calculated as below. I don't think there is any equivalent to in_stat_buf in Rust code. I see that currently Rust coreutils uses 1024 as the default buffer size. Should we continue to use 1024 as the default buffer size?
   https://github.com/coreutils/coreutils/blob/9a29ee2903df183f904cfd61f17e743ad9d2180b/src/split.c#L1588
   in_blk_size = io_blksize (in_stat_buf);

[tertsdiepraam]

It probably doesn't map very well to uutils. We mostly just want it to not panic so we pass the test, which just means to make it accept the flag and then just ignore it. That being said, I think it indeed specifies the buffer size, so that could be way to actually use it.

[ghost]

I created a pull request. I assume test failures are not related to the change.