azure-sdk-for-go AppendBlock operation resolves to AppendBlobHandler.create()

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

blob

### Which version of the Azurite was used?

Latest (v3.11.0)

### Where do you get Azurite? (npm, DockerHub, NuGet, Visual Studio Code Extension)

DockerHub (`mcr.microsoft.com/azure-storage/azurite:3.11.0`)

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

Whatever the `mcr.microsoft.com/azure-storage/azurite:3.11.0` docker container is running

### What problem was encountered?

[`Blob.AppendBlock`](https://github.com/Azure/azure-sdk-for-go/blob/fd8f067989702b281ebb4177ddfbbba2651583e4/storage/appendblob.go#L70) gets resolved to [`AppendBlobHandler.create()`](https://github.com/Azure/Azurite/blob/456cbe74ca5c78b49e551b2659897ddf0d035b3c/src/blob/handlers/AppendBlobHandler.ts#L20) instead of [`AppendBlobHandler.appendBlock()`](https://github.com/Azure/Azurite/blob/456cbe74ca5c78b49e551b2659897ddf0d035b3c/src/blob/handlers/AppendBlobHandler.ts#L99). This is happening because the API specification [requires](https://github.com/Azure/Azurite/blob/456cbe74ca5c78b49e551b2659897ddf0d035b3c/swagger/blob-storage-2019-02-02.json#L7631-L7639) the `comp` query parameter for the `AppendBlob_AppendBlock` operation, while the `AppendBlob_Create` operation [requires](https://github.com/Azure/Azurite/blob/456cbe74ca5c78b49e551b2659897ddf0d035b3c/swagger/blob-storage-2019-02-02.json#L4285-L4300) the `x-ms-blob-type` header, which makes it equivalent to the `AppendBlob_Create` operation in [`dispatchMiddleware`](https://github.com/Azure/Azurite/blob/456cbe74ca5c78b49e551b2659897ddf0d035b3c/src/blob/generated/middleware/dispatch.middleware.ts#L47) (keys 59 and 60 return the same `conditionsMet`) because both of them contain the `Content-Length` header.

Would it be possible to make the `x-ms-blob-type` header mandatory for the `AppendBlob_AppendBlock` operation? This will probably require doing the same for `AppendBlob_AppendBlockFromUrl`, so it won't end up being confused with `AppendBlob_AppendBlock`. I'm happy to submit a PR for this if you can provide the steps to re-generate the code from the swagger definition.

### Steps to reproduce the issue?

Run the following code:

```go
package main

import (
"io/ioutil"
"log"
"time"

"github.com/Azure/azure-sdk-for-go/storage"
"github.com/google/uuid"
"github.com/ory/dockertest/v3"
"github.com/ory/dockertest/v3/docker"
)

// RunAzurite starts an azurite container
func RunAzurite(pool *dockertest.Pool) (*dockertest.Resource, error) {
opts := dockertest.RunOptions{
Repository: "mcr.microsoft.com/azure-storage/azurite",
Tag: "3.11.0",
PortBindings: map[docker.Port][]docker.PortBinding{
"10000/tcp": {{HostIP: "0.0.0.0", HostPort: "10000"}},
},
Cmd: []string{"azurite", "--blobHost", "0.0.0.0", "--loose"},
}
azurite, err := pool.RunWithOptions(&opts)
if err != nil {
return nil, err
}
if eerr := azurite.Expire(10); eerr != nil {
return nil, eerr
}
pool.MaxWait = 10 * time.Second
rerr := pool.Retry(func() error {
client, eerr := storage.NewEmulatorClient()
if eerr != nil {
return eerr
}
s := client.GetBlobService()
c := s.GetContainerReference("cont")
if _, err = c.Exists(); err != nil {
return err
}
return nil
})
return azurite, rerr
}

func main() {
pool, err := dockertest.NewPool("")
if err != nil {
log.Fatalf("Failed to create dockertest pool: %s", err)
}

azurite, err := RunAzurite(pool)
defer pool.Purge(azurite)

if err != nil {
log.Fatalf("Failed to start Azurite: %s", err)
}

client, err := storage.NewEmulatorClient()
if err != nil {
log.Fatalf("Failed to create storage client: %s", err)
}

blobClient := client.GetBlobService()
dummyContainer := uuid.New().String()
containerRef := blobClient.GetContainerReference(dummyContainer)

err = containerRef.Create(nil)
if err != nil {
log.Fatalf("Failed to create container: %s", err)
}

dummyBlob := uuid.New().String()
blobRef := containerRef.GetBlobReference(dummyBlob)

err = blobRef.PutAppendBlob(nil)
if err != nil {
log.Fatalf("Failed to create append blob: %s", err)
}

dummyData := uuid.New().String()
err = blobRef.AppendBlock([]byte(dummyData), nil)
if err != nil {
log.Fatalf("Failed to write to append blob: %s", err)
}

blob, err := blobRef.Get(nil)
if err != nil {
log.Fatalf("Failed to get blob: %s", err)
}

data, err := ioutil.ReadAll(blob)
if err != nil {
log.Fatalf("Failed to read blob: %s", err)
}

if string(data) != dummyData {
log.Fatalf("Expected %q but received %q instead", dummyData, string(data))
}

log.Print("That's all folks!")
}
```

### Have you found a mitigation/solution?

Sadly, no workaround...

Would it be possible to make the `x-ms-blob-type` header mandatory for the `AppendBlob_AppendBlock` operation? This will probably require doing the same for `AppendBlob_AppendBlockFromUrl`, so it won't end up being confused with `AppendBlob_AppendBlock`. I'm happy to submit a PR for this if you can provide the steps to re-generate the code from the swagger definition.

I would very much hope to see this fixed, if possible. Upgrading to the new azure-storage-blob-go API is not feasible for now (although I think that one might encounter the same issue).