SyncCopyFromUri and SyncCopyFromUriAsync always throws Azure.RequestFailedException (Blob Not Found)

First off, thanks for all the work on this. Azurite has been a nice addition for our local dev. So our team appreciates it quite a bit.

### Which service(blob, file, queue, table) does this issue concern?
Blob.

### Which version of the Azurite was used?
3.11.0

### Where do you get Azurite? (npm, DockerHub, NuGet, Visual Studio Code Extension)
Visual Studio Code Extension and npm running on Windows.

### What's the Node.js version?
15.12.0

### What problem was encountered?

Note: This setup is done through a C# app using the `Azure.Storage.Blobs` library, version 12.8.1.

When attempting to use the `SyncCopyFromUri` API to move a file from a publicly accessible URL into a container within an Azurite storage account, we continually get a 404 Not Found exception. When executing this against a storage account in Azure, it completes the transfer as expected without an exception.

What I'm unsure of is if Azure is the correct result or if the emulator is the correct result. I'm hoping it's Azure, because that makes this feature incredibly useful. Also for some reason, `SyncCopyFromUri` computes the MD5 hash server-side for an integrity check, whereas `Upload` does not seem to. So this additional feature is pretty vital for us.

The exception message:

```
Azure.RequestFailedException: The specified blob does not exist.
RequestId:...
Time:...
Status: 404 (The specified blob does not exist.)
ErrorCode: BlobNotFound

Headers:
Server: Azurite-Blob/3.11.0
x-ms-error-code: BlobNotFound
x-ms-request-id: ...
Date: ...
Connection: keep-alive
Transfer-Encoding: chunked
Content-Type: application/xml

at Azure.Storage.Blobs.BlobRestClient.Blob.CopyFromUriAsync_CreateResponse(ClientDiagnostics clientDiagnostics, Response response)
at Azure.Storage.Blobs.BlobRestClient.Blob.CopyFromUriAsync(ClientDiagnostics clientDiagnostics, HttpPipeline pipeline, Uri resourceUri, Uri copySource, String version, Nullable`1 timeout, IDictionary`2 metadata, Nullable`1 tier, Nullable`1 sourceIfModifiedSince, Nullable`1 sourceIfUnmodifiedSince, Nullable`1 sourceIfMatch, Nullable`1 sourceIfNoneMatch, Nullable`1 ifModifiedSince, Nullable`1 ifUnmodifiedSince, Nullable`1 ifMatch, Nullable`1 ifNoneMatch, String ifTags, String leaseId, String requestId, Byte[] sourceContentHash, String blobTagsString, Boolean async, String operationName, CancellationToken cancellationToken)
at Azure.Storage.Blobs.Specialized.BlobBaseClient.SyncCopyFromUriInternal(Uri source, IDictionary`2 metadata, IDictionary`2 tags, Nullable`1 accessTier, BlobRequestConditions sourceConditions, BlobRequestConditions destinationConditions, Boolean async, CancellationToken cancellationToken)
at Azure.Core.Pipeline.TaskExtensions.EnsureCompleted[T](Task`1 task)
at Azure.Storage.Blobs.Specialized.BlobBaseClient.SyncCopyFromUri(Uri source, BlobCopyFromUriOptions options, CancellationToken cancellationToken)
```

### Steps to reproduce the issue?

Note: This setup is done through a C# app using the `Azure.Storage.Blobs` library, version 12.8.1. Again it appears to work fine within Azure directly.

1. Install Azurite in VSC or in Node (I have not tried it with Docker).
2. Connect to the storage account. This can be done locally or remotely.
3. Setup a `BlobClient` with the name `StorageExplorer_signed.zip`.
4. Using the `BlobClient` instance, execute `SyncCopyFromUri` or `SyncCopyFromUriAsync` with a URL that is not in an Azure storage account specifically but is publicly accessible. Example: [the Storage Explorer download for OSX](https://download.microsoft.com/download/A/E/3/AE32C485-B62B-4437-92F7-8B6B2C48CB40/StorageExplorer_signed.zip) will reproduce the issue.

### Have you found a mitigation/solution?

The only workaround I can see is to manually do what `SyncCopyFromUri` seems to do (download locally, upload to the Storage Account, download from the storage account, hash the contents and compare the hashes).