cmd/utils: max out the OS file allowance, don't cap to 2K

[karalabe]

Supersedes #17597, as it can achieve the same results without any flags (i.e. automagically), whilst also ensuring we don't accidentally go over any OS limits (panic in leveldb).

Fast sync benchmarks, 4096 cache, i3.2xlarge (post sync):

The curious thing here is that memory usage seems to be a lot lower and more stable, which is an interesting find. Why would more file descriptors cause less memory? Perhaps there's some issue in leveldb which leaks memory, at least temporarily? Idea: perhaps it's the transaction pool, not the database!

Full sync bnchmarks, 2084 cache, i3.2xlarge:

The speed seems to be more or less the same (4h difference over the course of 4 days, might as well just be a slightly different machine). Database IO wise the "infinite" file descriptors do seem to result in a a 6-7% lower rate. Probably nothing spectacular.

---

All in all benchmarks point that there's nothing spectacular happening with this PR, at least on the Linux VMs. I think it's safe to merge just to get rid of an artificial limit we had in our code until now.

[holiman]

The code LGTM, but we should probably try it out on the benchmarking nodes. Although, we could also just merge it to master as soon as possble to get maximum testing on various platforms before next release

[karalabe]

Would be interesting to see the speed effect. Lets leave the leveldb 128MB thing running for a day and if the results are conclusive we can replace that benchmark with this one.