[FEATURE REQ]Provide a way to know whether a container has hierarchical namespace enabled for vended credentials

**Is your feature request related to a problem? Please describe.** This is a follow-up of the initial feature request https://github.com/Azure/azure-sdk-for-java/issues/38912 Based on the new capability added when completing the above mentioned issue, the check whether HNS is enabled can be done relatively straightforward: ``` createBlobContainerClient(location, Optional.empty()) .getServiceClient() .getAccountInfo() .isHierarchicalNamespaceEnabled(); ``` This approach needs though elevated permissions for the service principal calling it ("Storage Account Contributor" role) AND it does not work unfortunately for vended credentials (which are directory scoped, not storage account scoped). **Describe the solution you'd like** Provide an API which can be used without any **elevated permissions** (having "Storage Blob Data Reader" role should be enough) AND which works as well with SAS vended credentials for figuring out whether the storage account corresponding to an Azure location has HNS enabled. **Describe alternatives you've considered** Based on the new capability added when completing the issue https://github.com/Azure/azure-sdk-for-java/issues/38912, the check whether HNS is enabled can be done relatively straightforward: ``` createBlobContainerClient(location, Optional.empty()) .getServiceClient() .getAccountInfo() .isHierarchicalNamespaceEnabled(); ``` However, as described in https://github.com/trinodb/trino/pull/27278 , this approach needs unfortunately elevated permissions. ``` "message":"Checking whether hierarchical namespace is enabled for the location abfs://xxx/.... failed", "cause":{ "type":"com.azure.storage.blob.models.BlobStorageException", "message":"If you are using a StorageSharedKeyCredential, and the server returned an error message that says 'Signature did not match', you can compare the string to sign with the one generated by the SDK. To log the string to sign, pass in the context key value pair 'Azure-Storage-Log-String-To-Sign': true to the appropriate method call.\nIf you are using a SAS token, and the server returned an error message that says 'Signature did not match', you can compare the string to sign with the one generated by the SDK. To log the string to sign, pass in the context key value pair 'Azure-Storage-Log-String-To-Sign': true to the appropriate generateSas method call.\nPlease remember to disable 'Azure-Storage-Log-String-To-Sign' before going to production as this string can potentially contain PII.\nIf you are using a StorageSharedKeyCredential, and the server returned an error message that says 'Signature did not match', you can compare the string to sign with the one generated by the SDK. To log the string to sign, pass in the context key value pair 'Azure-Storage-Log-String-To-Sign': true to the appropriate method call.\nIf you are using a SAS token, and the server returned an error message that says 'Signature did not match', you can compare the string to sign with the one generated by the SDK. To log the string to sign, pass in the context key value pair 'Azure-Storage-Log-String-To-Sign': true to the appropriate generateSas method call.\nPlease remember to disable 'Azure-Storage-Log-String-To-Sign' before going to production as this string can potentially contain PII.\nStatus code 403, \"•<?xml version=\"1.0\" encoding=\"utf-8\"?><Error><Code>AuthorizationPermissionMismatch</Code><Message>This request is not authorized to perform this operation using this permission.\nRequestId:9dd14fea-f01e-0067-38ce-520758000000\nTime:2025-11-11T05:48:27.2395973Z</Message></Error>\"", ``` NOTE the Status code 403 in the above message. This happens when the Azure role "Storage Account Contributor" is missing on the service principal for storage account on which we're checking whether the hierarchical namespace is enabled. That's the approach the project `trinodb/trino` currently uses to figure out whether a storage account has HNS enabled: ``` BlockBlobClient blockBlobClient = createBlobContainerClient(location, Optional.empty()) .getBlobClient("/") .getBlockBlobClient() .blockBlobClient.exists(); ``` With the advent of vended credentials, the above mentioned approach doesn't work anymore because the vended credentials are directory scoped and not container scoped. What we're currently trying is a rather non-conventional approach on checking via `getAccessControl()` method the error code to figure out whether we're dealing of not with a HNS enabled storage account: ``` private boolean isHierarchicalNamespaceEnabledWithVendedCredentials(AzureLocation location) throws IOException { try { String path = location.path(); while (path.endsWith("/")) { path = path.substring(0, path.length() - 1); } DataLakeFileSystemClient fileSystemClient = createFileSystemClient(location, Optional.empty()); fileSystemClient.getDirectoryClient(path).getAccessControl(); return true; } catch (DataLakeStorageException e) { // getAccessControl() is only supported on HNS-enabled accounts; flat namespace returns HierarchicalNamespaceNotEnabled if ("HierarchicalNamespaceNotEnabled".equals(e.getErrorCode())) { return false; } // Path does not exist yet (e.g. creating a new nested directory), but the account supports HNS if (e.getStatusCode() == 404) { return true; } throw new IOException("Checking whether hierarchical namespace is enabled for the location %s failed".formatted(location), e); } catch (RuntimeException e) { throw new IOException("Checking whether hierarchical namespace is enabled for the location %s failed".formatted(location), e); } } ``` Related PR https://github.com/trinodb/trino/pull/29947 **Additional context** Add any other context or screenshots about the feature request here. **Information Checklist** Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report - [x] Description Added - [x] Expected solution specified