For example, if we're both seeds, or if the peer is not connectible, don't bother caching it for the next session. If it's still alive, we'll find it up through DHT or tracker announces next time around. As with r12253, this commit's intention is to reduce the number of unproductive peer_atoms that we waste time trying to connect to.
This is partially to address #4145 "Downloads stuck at 100%" by refactoring the bitset, bitfield, and tr_completion; however, the ripple effect is larger than usual so things may get worse in the short term before getting better.
livings124: to fix the mac build, remove bitset.[ch] from xcode
As pointed out by longinus00 and ijuxda, storing per-piece timestamps in the .resume file can involve a lot of overhead. This commit reduces the overhead by adding a couple of optimizations: (1) in cases where *all* or *none* of the files' pieces were checked after the file's mtime, we can safely fold all the pieces' mtimes into a single per-file mtime. (2) since unix time takes up a lot of space when rendered as a benc integer, find a common per-file "baseline" number, then store the pieces' timestamps as offsets from that number. Also add documentation explaining this new format, and also better explaining the pre-2.20 progress format.
Super-poussin says some readynas users are reporting high CPU oloads in 2.20 beta 1. My guess is this is due to pieces being reverified. Before now, the .resume files kept timestamps per-file, and 2.20 keeps timestamps per-piece. The problem is that 2.20 beta 1 didn't support reading the older per-file timetstamps from .resume files, so users loading up 2.20 beta 1 may find Transmission thinks none of the pieces in the torrents have been verified.
The fix is to have 2.20 beta 2 read the old per-file timestamps, so upgrading from 2.1x to 2.20 will go smoothly. That's what this commit does.
Unfortunately, the readynas users who have already been bitten by this will continue to be bitten until they reverify their files. 2.20 beta 1, which thinks all those pieces were never verified, has probably overwritten the .resume files from 2.1x... :(
The Berne Convention says that the copyright year is moot, so instead of adding another year to each file as in previous years, I've removed the year altogether from the source code comments in libtransmission, gtk, qt, utils, daemon, and cli.
Juliusz's copyright notice in tr-dht and Johannes' copyright notice in tr-lpd have been left alone; it didn't seem appropriate to modify them.
There used to be two versions of tr_isPex; one correct in peer-mgr.c,
and one buggy in resume.c. The buggy version caused us to reject all
peers with non-trivial flags when resuming.
