Add a 'canceled' signal

[Barry Warsaw]

I think we need a 'canceled' signal that will inform the client when a 'cancel' request has been fulfilled. Without this, I think we have a bit of a race condition and/or ambiguity.

In normal usage, the client will request downloading for several files in parallel. The client only cares about all-or-nothing, i.e. all the files get downloaded successfully or none of them do. This semantic isn't the responsibility of d/l service, but right now we can't reliably implement it on top of the current API.

Let's say we request files A, B, and C. File A is missing or gets an error, and we'll see its Download object get an `error` signal. Now we want to cancel all outstanding downloads, since we don't care about them, so we cancel B and C. In the meantime though B actually completed, and we'll see its `finished` signal - we can just delete that file. But what about C? If it got successfully canceled, we won't know it until we timeout our wait loop so at best, it's wasteful. At worst, we'll never get the `finished` signal or the `error` signal and so we'll never know whether we need to clean up the destination file or not, or even when it's safe to do so.

A `canceled` signal would tell us that the cancel was processed, and that there's nothing to clean up.

[Barry Warsaw (barry)]

There was always a canceled signal, it just wasn't documented.