az vm boot-diagnostics get-boot-log: Output is a mess with managed storage account

### Describe the bug

If you use managed storage account for boot-diagnostics on a linux vm, the output of
```
az vm boot-diagnostics get-boot-log --ids
```
is a mess. E.g. it contains linefeed characters and plain unicode character instead of line breaks or dissolve those characters.

Tested with centos 9 stream and suse linux enterprise server 15 SP5.

With a custom storage account, the output is ok.

If you use the linux curl command on the serialConsoleLogBlobUri received by
```
az vm boot-diagnostics get-boot-log-uris --ids
```
the output is ok in both cases. E.g.
```
curl "https://xxx.blob.core.windows.net:443/bootdiagnostics-tstazcen9-xxx=r" --output -
```

### Related command

Step to reproduce

Enable boot-diagnostics with managed storage account (omit --storage parameter)
```
az vm boot-diagnostics enable --ids /subscriptions/${SUBSCRIPTION}/resourceGroups/${RG}/providers/Microsoft.Compute/virtualMachines/tstazcen9
```

The blob is created if new output is printed to the console. To trigger this:
- Log in to the azure portal web interface
- Open the serial console of the vm
- type data there, eg try a login to the vm from console

Wait 5min (the blob needs time until it is created)

Get the boot log output:
```
az vm boot-diagnostics get-boot-log --ids /subscriptions/${SUBSCRIPTION}/resourceGroups/${RG}/providers/Microsoft.Compute/virtualMachines/tstazcen9
"test\r\r\nPassword: \r\nLogin incorrect\r\n\r\ntstazcen9 login: login: timed out\r\r\nCentOS Stream 9\r\nKernel 5.14.0-267.el9.x86_64 on an x86_64\r\n\r\ntstazcen9 login: \u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000"
```

Do the same with a custom storage account, the output is ok.

### Errors

see above

### Issue script & Debug output

The issue is easy to reproduce and a debug log can be created by following the steps to reproduce.

In the debug log you see that the az cli gets the serialConsoleLogBlobUri, the connects with urllib3.connectionpool connection to retrieve the log
```
cli.azure.cli.core.sdk.policies: Request URL: 'https://management.azure.com/subscriptions/xxx/providers/Microsoft.Compute/virtualMachines/tstazcen9/retrieveBootDiagnosticsData?api-version=2024-03-01'
...
urllib3.connectionpool: Starting new HTTPS connection (1): xxx.blob.storage.azure.net:443
urllib3.connectionpool: https://xxx.blob.storage.azure.net:443 "GET /xxx/tstazcen9.xxx.serialconsole.log?xxx=r HTTP/11" 200 512
...
cli.knack.cli: Event: CommandInvoker.OnFilterResult []
"\r\r\ntstazcen9 login: \r\r\ntstazcen9 login: test\r\r\nPassword: \r\n ...
```

If we do the same, but use curl, it works:
```
az vm boot-diagnostics get-boot-log-uris --ids /subscriptions/${SUBSCRIPTION}/resourceGroups/${RG}/providers/Microsoft.Compute/virtualMachines/tstazcen9
{
"consoleScreenshotBlobUri": "...",
"serialConsoleLogBlobUri": "https://xxx.blob.storage.azure.net:443/xxx/tstazcen9.xxx.serialconsole.log?xxx=r"
}
curl "https://xxx.blob.storage.azure.net:443/xxx/tstazcen9.xxx.serialconsole.log?xxx=r" --output -
test
Password:
Login incorrect

tstazcen9 login: login: timed out
CentOS Stream 9
Kernel 5.14.0-267.el9.x86_64 on an x86_64

tstazcen9 login:
```

### Expected behavior

Format should be ok in both cases, similar to linux curl

### Environment Summary

# az --version
azure-cli 2.62.0

core 2.62.0
telemetry 1.1.0

Dependencies:
msal 1.28.1
azure-mgmt-resource 23.1.1

Python location 'xxx/azurecli/bin/python3.11'
Extensions directory 'xxx/.azure/yyy/cliextensions'

Python (Linux) 3.11.9 (main, Jun 11 2024, 00:00:00) [GCC 11.4.1 20231218 (Red Hat 11.4.1-3)]

Legal docs and information: aka.ms/AzureCliLegal

Your CLI is up-to-date.

### Additional context

_No response_