Tweak the candidate path scoring algorithm

In the course of investigating LP: #1250181 we encountered another issue. When some of the delta images were pulled from the server, it lead to a winning upgrade path through broken deltas (of course s-i doesn't know the deltas were broken).

The reason this path one is because of how sizes and distance-from-max-build are added together. In this case, there was an upgrade path 16:17 and an upgrade path 20. Because 20-17 == 3 and we only add 1 for distance-from-max, and because the path ending at 17 was the smallest upgrade, it ended up winning. The path through 20 was > 3MiB larger than the path through 17, so it ended up with a higher score (we add 1 for every MiB > the smallest image).

stgraber and I discussed a tweak to the scoring algorithm which would prevent this bogus winner.

Instead of adding 1 for distance-from-max, we'll first filter out any candidate path that doesn't lead to the highest build number. Then we do the scoring as normal: add 1 for every MiB > smallest + 100 for every reboot flag.

The caveat here is that the server has to guarantee that every upgrade path leads to the maximum build number, even if it's only through a full upgrade. E.g. if there are only deltas offered, but none of the delta paths leave you at the max, you'll filter all of them out and the device will think it's up-to-date (i.e. there are no candidate upgrade paths available). stgraber thinks this is a reasonable assumption. Still, I think that's the worst that can happen, and --filter=full or -b 0 will probably unstick you albeit only through the cli.