Move to modern `@azure/*` packages with functional-style exports

🤖

Summary

Move the @azure/* dependencies to their most modern versions, which expose a functional-style (modular, tree-shakeable) API surface that bundles at a small fraction of the current size.

Motivation

Investigation into the 2.4.0 code-loading regression found that the Azure SDK packages dominate the lazily-loaded portion of the bundle. From a reachability analysis of the esbuild metafile (unminified byte counts, current main):

That is roughly 3.5 MB of the 4.73 MB that is reachable only via await import(). These are already lazily loaded via src/utils/lazyPackages.ts, so they are not on the activation critical path today — but they are the single largest contributor to overall bundle size, and they materially constrain any bundling strategy we choose.

The older client-class-based SDKs are effectively untreeshakeable: the generated clients pull in the full operation surface plus the @azure/core-* stack regardless of how few operations we actually call. The modern functional/modular exports are designed to be tree-shaken, so we would ship only the operations we use.

Current versions are also well behind:

• @azure/arm-containerregistry: ^10.1.0 (latest 12.0.0)
• @azure/storage-blob: ^12.14.0 (latest 12.33.0)

Expected benefits

• Substantially smaller VSIX and smaller on-disk footprint.
• Less code to read/parse whenever registry or blob functionality is first used.
• Meaningfully more headroom for whichever bundling approach we adopt (see below) — in particular it shrinks the duplicated @azure/core-* mass that any code-splitting scheme has to account for.
• Picks up several major versions of upstream fixes and security updates.

Scope

• @azure/arm-containerregistry — used via getArmContainerRegistry() in lazyPackages.ts; consumers include AzureRegistryDataProvider and related registry code.
• @azure/storage-blob — used via getStorageBlob().
• @microsoft/vscode-azext-azureutils transitively pulls @azure/arm-resources, arm-storage, arm-authorization, arm-msi and the *-profile-2020-09-01-hybrid variants. Reducing those likely requires a coordinated change in microsoft/vscode-azuretools rather than here.

Migrating to the functional API is a breaking-shape change at each call site (client classes → standalone operation functions), so this should be done deliberately with registry and blob-upload paths manually exercised.

Related

Part of the broader activation-performance work tracked from the 2.4.0 code-loading regression. Two adjacent items surfaced by the same investigation:

• The extension entry bundle grew from 1.84 MB (webpack, 2.3.0) to 2.85 MB (esbuild, 2.4.0+) because esbuild has no code splitting in CJS output, so lazily-imported code is inlined into the entry file instead of being emitted as separate on-demand chunks. This is the direct cause of the regression and is being addressed separately.
• @microsoft/vscode-azext-utils's parseError eagerly pulls in html-to-text (~0.25 MB, ~13% of the eager set). Worth a separate upstream issue against vscode-azuretools.

Start with src/utils/lazyPackages.ts and trace getArmContainerRegistry() and getStorageBlob() into AzureRegistryDataProvider and the blob-upload paths. Update the package usage to the functional Azure APIs, then manually exercise registry and blob-upload flows and verify that the resulting bundle is smaller.