[Storage] get_blob_properties for BlobClient

[vincenttran-msft]

This PR contains the following:

• Fleshed out implementation of BlobClient to support get_blob_properties
• get_blob_properties and simple test cases (get properties with existing blob, container not exists case)

Will fix in upcoming PR.

[vincenttran-msft]

Hi @heaths Heath, I have documented the remaining 4 feedback items into my notes, and will address them in the following PR. I have commented out the testcases since they currently rely on static resources and have a hard dependency on some NYI functionality. With that in mind- please let me know if there is any other showstoppers in this specific PR. Thanks!

[vincenttran-msft]

I was under the impression this PR was no longer passing due to merging in main and messing up the Cargo.lock, but even after attempting to merge again and cargo generate lock-file, I am still hitting some errors here. Some assistance on getting CI green alongside the review would be greatly appreciated!

[vincenttran-msft]

Hi @heaths Heath, whenever you get a free moment if you could take a look at this to help resolve the CI issues and any merge-blocking stoppers. Thanks!

[heaths]

Hi @heaths Heath, whenever you get a free moment if you could take a look at this to help resolve the CI issues and any merge-blocking stoppers. Thanks!

@vincenttran-msft you need to fetch upstream/main and rebase on it. The issues you are running into were fixed in main. Don't merge, but rebase.

[vincenttran-msft]

@heaths I have addressed your comments, rebased, and resolved the Build Pack Crates issue by changing
azure_core_test.workspace = true -> azure_core_test.path = "../../core/azure_core_test"
under dev-dependencies in the Cargo.toml.

The remaining error is in the "Build Analyze" step, specifically Run source analysis:

Checking azure_security_keyvault_test v0.1.0 (/mnt/vss/_work/1/s/sdk/keyvault/azure_security_keyvault_test)
Invoke-LoggedCommand: /mnt/vss/_work/1/s/eng/scripts/Analyze-Code.ps1:33
Line |
  33 |    Invoke-LoggedCommand "cargo +$Toolchain clippy --target=wasm32-unkn …
     |    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | ##[error]Command failed to execute (00:00:53.4807897): cargo +stable
     | clippy --target=wasm32-unknown-unknown --workspace --keep-going --no-deps

##[error]PowerShell exited with code '1'.
Finishing: Run source analysis

It seems to be having issues while checking azure_security_keyvault_test v0.1.0, any ideas? Thanks!

[heaths]

Building and testing all features in the workspace works fine on my machine. There were some changes that went in today that may fix them, though. Try rebasing again.

[heaths]

The command failing here works fine on my box, and I just pulled upstream/main once again:

cargo +stable clippy --target=wasm32-unknown-unknown --workspace --keep-going --no-deps

You've been merging (in general, don't do that unless you're trying to main history for some reason), and I'm guessing you have a bad merge at some point. If all your changes have been under sdk/storage, I recommend from within your topic branch:

git fetch upstream main
git rebase -X theirs upstream/main

The problem you're running into is something I believe I fixed last Friday (was merged today, Monday).

[heaths]

Also, I believe your merge is dirty because at one point Cargo.lock was accidentally upgraded to all new versions, which caused some issues with getrandom used by uuid. I had to downgrade uuid from 0.3 to 0.2 (what we had) because of it; lots of people are running into this problem because of a breaking change in getrandom and because we have dependencies that take a dependency on an older version: the workaround for the older and newer versions conflicts with each other.

[vincenttran-msft]

@heaths Thanks for that callout. After merging and reverting the lockfile and doing a clean cargo build on the crate, we are now back to passing! Thanks for the help Heath, it should now be ready for a final review.

[heaths]

A couple nits/tips but nothing blocking. LGTM