Increase priorities in DownloadPriority from 7 to 32

[cbordeman]

in the enum class DownloadPriority : int
{
Ignored = 0,
Normal = 1,
High = 6,
Maximum = 7,
...increase the possible values to 32 or so, enough to accomodate Fine Grained File Priorities in qBitTorrent, see fearure request here

[HanabishiRecca]

Wrong code snippet though. That's from qBittorrent's code.
LT's one is:

libtorrent/include/libtorrent/download_priority.hpp

Lines 42 to 53 in 4479071

	// Don't download the file or piece. Partial pieces may still be downloaded when
	// setting file priorities.
	constexpr download_priority_t dont_download{0};
	// The default priority for files and pieces.
	constexpr download_priority_t default_priority{4};
	// The lowest priority for files and pieces.
	constexpr download_priority_t low_priority{1};
	// The highest priority for files and pieces.
	constexpr download_priority_t top_priority{7};

libtorrent/src/torrent.cpp

Line 5670 in 4479071

prio = aux::clamp(prio, dont_download, top_priority);

[arvidn]

file priorities turn into piece priorities, and so priority values are stored per piece. Since there are a lot of pieces, the priority is currently only allotted 3 bits right now.

See the piece picker: https://github.com/arvidn/libtorrent/blob/RC_2_0/include/libtorrent/piece_picker.hpp#L671-L679

The counter for number of peers that have a piece has 26 bits, allowing 67 million peers. Perhaps a few bits can be taken from that field.

However, there are some parts of the piece picker that grows proroprtionally to the number of priority levels, and may slow things down. It may not be a big deal, but it's also not trivial to make this change.

[HanabishiRecca]

In the context of qbittorrent/qBittorrent#23751 (comment), I wonder how reasonable it is to just allocate a full standalone int32 field for priority.
I guess people are not that tight on memory nowdays. Although there are routers and other embedded devices. So it would be interesting to calculate the overhead of such change.