There are many race conditions around cancelling
SDWebImageDownloaderOperation instances from other threads. For example,
imageData may be set to nil and deallocated just as it is being appended
to, or the threading can interleave in such a way that messages are sent
to a deallocated connection. These were discovered using SDWebImage for
a Google Maps-style tiled mapping application where there is a lot of
download and cancellation if users pan rapidly.
This fix tracks the worker thread that the NSURLConnection instance runs on and
performs cancellation on the worker thread. The cancel and start methods need
to be synchronized to handle the case where cancellation happens before
start is called; since no thread has been assigned yet, cancellation is
performed on the calling thread.
Because cancellation is now scheduled on the same run loop as
NSURLConnectionDelegate callbacks, there is an added window of time that
a download can finish prior to cancellation. This means it's possible to
cancel an operation yet still get a successful completion callback. This
was always possible because of race conditions, but it is more
pronounced and predictable now. An application that relies on
a cancelled operation never calling its completion block (e.g. recycling
image views in a scrolling table view) must adopt some other mechanism
(e.g. a version number) to avoid running completion code for a stale operation.
