Change batch_size and ulimit type

[koloiyolo]

Issue

Hi while playing with Your tool i stumbled across this message:

[~] File limit higher than batch size. Can increase speed by increasing batch size '-b 524188'.

But when I ran tool with reccomended parametr I got:

➜  release git:(master) ./rustscan -a www.google.com -b 524188
error: invalid value '524188' for '--batch-size <BATCH_SIZE>': 524188 is not in 0..=65535

For more information, try '--help'.

After further inspection I found out that batch_size is u16 which indeed can hold up to 65535, and that is way lower than some OSes can use.

My OS info

OS	Kernel	ulimit -Hn	CPU
Fedora 42 Workstation	x86_64 Linux 6.15.6-200.fc42.x86_64	524288	i7 7500u

Thought process

• Considering that batch_size variable is directly tied to ulimit variable it made sense for those 2 variables to use the same type. Especially when those values are being compared.
• Considering that ulimit is directly tied to OS and OS architecture it made sense for this type to be usize which is affected by OS architecture.

Also quick thought. Capping the batch_size based on OS ulimit may fix the issue described here.

What does it change

• Let's user assign higher batch_size which may increase tool performance based on user's OS ulimits and may be helpful when scanning multiple addresses.
• Removes no longer needed conversions which may improve performance.
• Doesn't change defaults and current behavior of the tool.

Benchmarks

Using time on precompiled binaries with 'cargo build --release':

• Defaults:

./rustscan --greppable -a www.google.com  2.01s user 3.11s system 22% cpu 22.950 total
./rustscan --greppable -a www.google.com  1.89s user 3.04s system 21% cpu 22.955 total

• batch_size based on OS cap:

./rustscan --greppable -a www.google.com -b 524188  2.14s user 4.98s system 105% cpu 6.757 total
./rustscan --greppable -a www.google.com -b 65535  2.08s user 4.99s system 104% cpu 6.780 total
./rustscan --greppable -a www.google.com -b 65535  2.10s user 5.09s system 103% cpu 6.952 total

As You can see the higher batch size makes initial memory allocation a bit slower but overall program executions are way quicker.

[koloiyolo]

Seems the fail is not related to my changes.
(Edit) Fixed.