Work around CRAN metadata inconsistencies on macos

[gaborcsardi]

Cf. #838, r-lib/actions#1040, etc.

[gaborcsardi]

Cf. r-lib/actions#1040 (comment)

The metadata has the old version number, but the corresponding package file is already gone, only the new package is there. True for both cloud.r-project.org and cran.r-project.org. I don't know if mac.r-project.org is always consistent or also has issues.

In any case, using mac.r-project.org directly is not great, because it is pretty slow, at least from Europe:

❯ ping -c 3 mac.r-project.org
PING mac.urbanek.info (169.60.149.197): 56 data bytes
64 bytes from 169.60.149.197: icmp_seq=0 ttl=49 time=182.991 ms
64 bytes from 169.60.149.197: icmp_seq=1 ttl=49 time=179.785 ms
64 bytes from 169.60.149.197: icmp_seq=2 ttl=49 time=214.962 ms

--- mac.urbanek.info ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 179.785/192.579/214.962/15.881 ms

~
❯ ping -c 3 cloud.r-project.org
PING d3caqzu56oq2n9.cloudfront.net (52.222.132.123): 56 data bytes
64 bytes from 52.222.132.123: icmp_seq=0 ttl=248 time=41.124 ms
64 bytes from 52.222.132.123: icmp_seq=1 ttl=248 time=59.794 ms
64 bytes from 52.222.132.123: icmp_seq=2 ttl=248 time=55.979 ms

--- d3caqzu56oq2n9.cloudfront.net ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 41.124/52.299/59.794/8.054 ms

I also cannot simply implement a fallback on download error, because when the download error happens the package file is already gone from both the CRAN mirror and mac.r-project.org as well.

We would need to detect the problem in the resolution phase, because the new package version might have different dependencies that we need to know about.