update auto piece size calculation

[Audionut]

The existing code has a hard defined limit of 8 MiB,.

This PR iterates through the piece sizes, up to 128 MiB piece size, to keep the piece count between 1000 and 2000.

[stalkerok]

I would significantly reduce the initial value, from 300.

[arvidn]

what's the motivation for this change? I imagine you want the .torrent file to be smaller, but it has to be weight against the performance of swarm as well, right?

[arvidn]

also, some torrent clients don't support piece sizes of 16 MB or greater

[Audionut]

To maintain performant piece counts without arbitrary limits.

If piece count was irrelevant, then a fixed size should be defined, reducing code clutter and uncertainty.

I am not aware of any relatively modern client having a 16 MiB piece size limit, nor am I sure why overall swarm performance should be limited because of 1 or 2 clients, that would seemingly wish to maintain updated libtorrent, but not also update their end, to support codebase changes.

[arvidn]

To maintain performant piece counts without arbitrary limits.

Please elaborate

I would expect performance to suffer from larger pieces, since you need to download more before you can start uploading.