Fix potential race conditions and refactor the unit tests
1. In the manager, backing image check and registration should be
done within one locking.
2. Considering the old backing image implementation, if the backing
image deletion happens before the actual downloading
pulling/receiving starts, the download cannot be cancelled.
3. State `starting` of BackingImage now means the backing image
init the downloading but the actual downloading is not started.
State `pending` means the backing image is just registered but
hasn't init the downloading. Then we can rely on the state to
refuse duplicate downloading calls.
4. In the downloader, we need to make sure the check & update
for the downloading related fields are atomic.
5. If the backing image state is empty but somehow the downloader
is not right, it's BackingImage's responsibility to cancel the
downloading. If the downloader finds that something is wrong with
the download context, it's the downloader's responsibility to
cancel the downloading and reset itself.
Signed-off-by: Shuo Wu <shuo.wu@suse.com>
