[Storage] stage_block, commit_block_list for BlobClient, get_container_properties for ContainerClient, ServiceClient

[vincenttran-msft]

This PR introduces the following:

BlobClient

• stage_block
• commit_block_list

ContainerClient

• get_container_properties

ServiceClient

• Initial introduction of ServiceClient
• get_service_properties

This PR also moves to the standardized way to fetch randomized seeded names (random_string) and includes a helper utility for test setup.

[heaths]

You have some clippy lints to resolve as well. Look at the failed build. It's a good idea to run this locally e.g., cargo clippy -p azure_storage_blob so you can quickly iterate on lints.

[vincenttran-msft]

You have some clippy lints to resolve as well. Look at the failed build. It's a good idea to run this locally e.g., cargo clippy -p azure_storage_blob so you can quickly iterate on lints.

Interesting, this doesn't manifest locally:

C:\azure-sdk-for-rust\sdk\storage>cargo clippy -p azure_storage_blob
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.75s

I also largely took that credential type hint that is problematic from Cosmos ex, so I am surprised Cosmos does not have the same error regarding redundant explicit links.

Regardless, I removed the duplicate explicit link and re-ran clippy locally (although I can't really trust the local output, as it didn't flag it even before the fix).

[heaths]

You have some clippy lints to resolve as well. Look at the failed build. It's a good idea to run this locally e.g., cargo clippy -p azure_storage_blob so you can quickly iterate on lints.

Interesting, this doesn't manifest locally:

C:\azure-sdk-for-rust\sdk\storage>cargo clippy -p azure_storage_blob
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.75s

I also largely took that credential type hint that is problematic from Cosmos ex, so I am surprised Cosmos does not have the same error regarding redundant explicit links.

Regardless, I removed the duplicate explicit link and re-ran clippy locally (although I can't really trust the local output, as it didn't flag it even before the fix).

If you look at the command in Azure Pipelines, it will use an explicit toolchain e.g., +stable or maybe +nightly. You need to use the same one. If you're using a different version (>= MSRV, as is required), the lints may not catch it (they get more and more pedantic with each subsequent toolchain version).

[heaths]

I don't see the lib.rs change. We don't want to be exposing all those submodules to clients.

[heaths]

I was trying to check out your branch when I realized you're not working in a fork. Please use forks on GitHub: fork your repo, push your branch to your fork, and open a PR normally. This not only yields in faster pull times, but also makes other workflows easier and is the GitHub way. Using a single shared repo is how Azure Repos operates but isn't the norm.