[Storage] get_account_info all clients, set/get_tags for BlobClient, set_properties for BlobServiceClient

[vincenttran-msft]

.tsp: Azure/azure-rest-api-specs#36677

BlobClientSetTagsResult
• ̶ ̶D̶a̶t̶e̶

BlobClientGetAccountInfoResult
• Date
• Account_kind
• Is_hns_enabled
• Sku_name

BlobContainerClientGetAccountInfoResult
• ̶ ̶D̶a̶t̶e̶
• Account_kind
• Is_hns_enabled
• Sku_name

BlobServiceClientGetAccountInfoResult
• ̶ ̶D̶a̶t̶e̶
• Account_kind
• Is_hns_enabled
• Sku_name

[github-actions]

API Change Check

APIView identified API level changes in this PR and created the following API reviews

azure_storage_blob

[Copilot]

Pull Request Overview

This PR adds new functionality to the Azure Storage Blob client library, implementing get_account_info for all clients, set/get_tags and start_copy_from_url for BlobClient, and set_properties for BlobServiceClient. These additions align with the Azure REST API specifications and provide essential blob management capabilities.

• Adds account information retrieval across all client types (BlobClient, BlobContainerClient, BlobServiceClient)
• Implements blob tagging functionality with set/get operations for BlobClient
• Adds blob copy functionality and service properties management

Reviewed Changes

Copilot reviewed 11 out of 14 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
sdk/storage/azure_storage_blob_test/src/lib.rs	Adds utility function for comparing blob tags in tests
sdk/storage/azure_storage_blob/src/parsers.rs	Implements blob tags serialization helper function
sdk/storage/azure_storage_blob/src/models/mod.rs	Exports new model types for account info, tags, and copy operations
sdk/storage/azure_storage_blob/src/clients/blob_service_client.rs	Adds set_properties and get_account_info methods
sdk/storage/azure_storage_blob/src/clients/blob_container_client.rs	Adds get_account_info method
sdk/storage/azure_storage_blob/src/clients/blob_client.rs	Adds start_copy_from_url, set_tags, get_tags, and get_account_info methods
sdk/storage/azure_storage_blob/tests/	Comprehensive test coverage for all new functionality

Comments suppressed due to low confidence (3)

sdk/storage/azure_storage_blob_test/src/lib.rs:124

• [nitpick] The function name test_blob_tag_equality doesn't follow the naming convention for utility functions. Consider renaming to compare_blob_tags or blob_tags_equal since it's not a test function itself but a helper for tests.

pub fn test_blob_tag_equality(tags1: BlobTags, tags2: BlobTags) -> bool {

sdk/storage/azure_storage_blob_test/src/lib.rs:125

• The variable name count_map is misleading since it stores key-value pairs from tags, not counts. Consider renaming to tag_map or first_tags_map to better reflect its purpose.

    let mut count_map = HashMap::new();

sdk/storage/azure_storage_blob/src/parsers.rs:50

• Variable names k and v are too short and unclear. Consider using more descriptive names like key and value to improve readability.

    for (k, v) in tags.into_iter() {

[vincenttran-msft]

Also, I believe I'm stumbling upon a pretty fun issue 😄
Since we refactored set_tags to accept a HashMap<String, String> and then call our helper to serialize it into the proper form, BlobTags, due to the unordered nature of HashMaps, the resultant BlobTags object can have two different forms, and this will trigger a test recording failure:
Scenario 1:

<Tags>
	<TagSet>
		<Tag>
			<Key>hello</Key>
			<Value>world</Value>
		</Tag>
		<Tag>
			<Key>ferris</Key>
			<Value>crab</Value>
		</Tag>
	</TagSet>
</Tags>",

Scenario 2:

<Tags>
	<TagSet>
		<Tag>
			<Key>ferris</Key>
			<Value>crab</Value>
		</Tag>
		<Tag>
			<Key>hello</Key>
			<Value>world</Value>
		</Tag>
	</TagSet>
</Tags>",

I am wondering if this is something we can resolve at the test proxy level (i.e. sort alphabetically before comparing) at least in areas where order shouldn't matter.

[heaths]

Don't waste time sorting in production. Even if you need to, there are more efficient ways of doing so in production code.

[heaths]

Need to fix a lint issue, but otherwise LGTM.