total_wanted not recalculated after force_recheck() with excluded files

[xiaoxinmm]

libtorrent version

2.0.x (reproduced on 2.0.11.0)

Problem

When some files have dont_download priority and are physically deleted from disk, calling force_recheck() does not recalculate total_wanted / total_wanted_done in torrent_status.

After the recheck completes, total_wanted still reflects a stale value — it no longer matches the sum of sizes of files with priority > dont_download.

Steps to reproduce

1. Add a multi-file torrent and download all files
2. Set one file's priority to dont_download (priority 0)
3. Physically delete that file from disk
4. Call force_recheck() on the torrent handle
5. After the check completes, inspect torrent_status::total_wanted

Expected: total_wanted reflects only the files with priority > 0
Actual: total_wanted shows a stale/incorrect value

Workaround

Calling prioritize_files() again after the recheck completes (with the same priorities) forces libtorrent to recalculate total_wanted correctly.

Context

This was reported downstream in qBittorrent as qbittorrent/qBittorrent#23151. We have a workaround PR that re-applies file priorities after recheck, but the root cause appears to be in libtorrent.

[glassez]

When some files have dont_download priority and are physically deleted from disk, calling force_recheck() does not recalculate total_wanted / total_wanted_done in torrent_status.

I've done some experiments. It seems that this description is not entirely correct.
First of all, total_wanted_done doesn't seem to have anything to do with it. It is updated correctly during recheck, so that the correct progress is displayed:

total_wanted should be recalculated once new file priorities are set, but it doesn't if torrent is completely downloaded (seeding).

Moreover, such a torrent starts downloading the unchecked (dont_download) file after rechecking:

...and write it all in .parts file:

[arvidn]

I think there's a chance this will fix it: #8200

Piece priorities are stored in the piece picker, so once we become a seed and the piece picker is removed, the piece priorities are lost. However, the file priorities are stored directly in the torrent object, so they are preserved. When we start a force-recheck, the piece picker is re-created, to track the pieces we end up finding on disk.

The problem was that the piece priorities of that new piece picker was not updated to reflect the file priorities.