Description
A common workflow is to repeatedly add code to a file and source it in. When reading or downloading data at the top of such a file takes a long time, one might instead select the part of the file after the download and evaluate that part of the file. It's easy to accidentally hit a shortcut or command to evaluate the whole file, though, so one may often accidentally start a download and want to cancel out, e.g., with C-c. However, the (normally very helpful!) download-retrying mechanism will actually catch this interrupt as an error and retry the download, stopping the user from resuming until they've interrupted it enough times or twice in quick succession (once during a download + once inside the retry-delay window).
It will likely be friendlier overall to detect such interrupts in the retrying mechanism and not retry in those cases. (There is a chance that a user doesn't realize it's a download taking some amount of time, and will decide against continuing on with the interrupt, but these seem outweighed by a user who doesn't C-c fast enough and feels "trapped" and restarts the process. Perhaps the latter could be addressed with a modification to the retry message rather than changing whether to retry and might be even better.)