Add importer-provider extension capability for infrastructure generation

[vhvb1989]

Summary

Adds a new importer-provider capability to the azd extension framework, enabling extensions to generate infrastructure (Bicep/Terraform) from project-specific definition formats.

This POC enables creating extensions for scenarios like #7425, where projects want to define infrastructure in languages like C# or TypeScript instead of writing Bicep directly. The demo extension illustrates this pattern using markdown files as an analogy — where the .md files with resource definitions play the role that .cs or .ts files would in a real implementation. The extension reads these definitions and produces the Bicep that azd provisions.

How it works

# azure.yaml
name: my-app
infra:
  importer:
    name: demo-importer    # extension-provided importer
    # options:              # extension-owned settings (optional)
    #   path: custom-folder
services:
  app:
    host: staticwebapp
    language: js
    project: ./src/app
    dist: dist

• azd provision: If no infra/ folder exists, the importer generates temporary Bicep at runtime
• azd infra gen: The importer generates Bicep files into infra/ (ejection)
• After ejection: azd uses the ejected files directly, skipping the importer (supports customization)

Key design decisions

• Importers live under infra.importer, not in the services list — services remain clean for deployable units only
• options is an extension-owned map — each extension defines its own settings (path, format, etc.) with its own defaults
• Infra override: Once infra/ exists with generated files, azd uses those and skips the importer
• Backward compatible: Aspire auto-detection via CanImport on services is preserved for existing projects

What is included

Core framework

• Importer interface with CanImport, Services, ProjectInfrastructure, GenerateAllInfrastructure
• ImportManager refactored from hardcoded DotNetImporter to pluggable []Importer list
• ImporterRegistry singleton for extension-registered importers
• ImporterConfig with extension-owned options map in provisioning.Options

gRPC layer

• importer.proto with bidirectional Stream RPC
• Extension SDK: ImporterProvider interface, ImporterManager, ImporterEnvelope
• Server-side ImporterGrpcService with capability verification
• ExternalImporter adapter implementing Importer over gRPC

Demo extension

• DemoImporterProvider reads .md files with azd-infra-gen/v1 front-matter header
• Parses resource definitions (resource group, static web app with azd-service-name tag)
• Generates main.bicep, main.parameters.json, resources.bicep
• Default folder: demo-importer/ (overridable via options.path)

Sample project (test/functional/testdata/samples/extension-importer/)

• Combines importer-generated infra with a deployable Static Web App service
• Works end-to-end with azd up to deploy to Azure

Documentation

• docs/extensions/extension-custom-importers.md — authoring guide

What is NOT included

• azd init integration: Extension importers are not invoked during azd init. The init command uses built-in appdetect with hardcoded language detectors. Extensions can work around this by adding their own init command (e.g., azd my-importer init), similar to azd ai agent init. A future project-detector capability could integrate extensions into azd init auto-detection, following the same strategy where extensions define what to detect and what to write.

Closes #7425

[jongio]

Issues to address:

• dotnet_importer.go:625 - nil ProjectConfig passed to generateAllInfrastructureFromConfig causes panic
• importer_external.go:158 - extension-provided file paths not validated for path traversal
• importer_service.go:89 - stale importer left in registry after extension disconnect
• importer.go:411 - HasAppHost now triggers for non-Aspire importers, causing incorrect CI behavior
• importer_external.go:245 - noop env var resolver mangles resource names
• extension_importer_test.go:102 - test comments say "infra synth" but actually runs "azd show"

[jongio]

[CRITICAL] Nil pointer panic in GenerateAllInfrastructure bridge

generateAllInfrastructureFromConfig dereferences p.Infra.Module, p.Infra.Path, and p.Path - all panic when p is nil. This path is hit whenever ImportManager.GenerateAllInfrastructure auto-detects an Aspire project (the interface dispatches here through the bridge).

Simple nil guards aren't sufficient either - the inner method uses filepath.Rel(p.Path, ...) to compute service manifest locations. Consider constructing a minimal ProjectConfig{Path: projectPath, Infra: DefaultProvisioningOptions} instead of passing nil.

[jongio]

[CRITICAL] Path traversal - extension-controlled file paths written without containment check

file.Path comes from the extension over gRPC and is joined directly into tmpDir without validation. A path like ../../.ssh/authorized_keys would escape the temp directory. Extensions are user-installed, but defense-in-depth still applies.

Validate that filepath.Clean(target) stays under tmpDir before writing.

[jongio]

[HIGH] Stale importer left in registry after stream close

Stream teardown removes the importer from providerMap but not from ImporterRegistry. The stale ExternalImporter stays in the registry with a dead broker - any subsequent call to it fails with a gRPC stream error instead of a clean "importer not available" message.

ImporterRegistry needs a Remove(name) method called here alongside the providerMap delete.

[jongio]

[HIGH] HasAppHost behavioral change - now triggers for non-Aspire importers

HasAppHost now delegates to HasImporter, which iterates all importers including extension-provided ones. Callers like pipeline_manager.go use this to decide Aspire-specific CI behavior (InstallDotNetForAspire: props.HasAppHost). A non-Aspire extension importer returning CanImport=true would incorrectly trigger .NET SDK installation in generated CI pipelines.

Either keep HasAppHost checking only the Aspire importer by name, or rename callers to distinguish Aspire-specific behavior from generic importer presence.

[jongio]

[MEDIUM] Noop env var resolver mangles resource names

The noop mapper func(string) string { return "" } replaces env var references with empty string - so rg-${AZURE_ENV_NAME} becomes rg-. This silently corrupts resource names sent to extensions. Use an identity mapper that preserves the template syntax, or send the raw unexpanded value.

[jongio]

[LOW] Test description doesn't match what it does

Comments reference "azd infra synth" but the test runs azd show (line 110). This is a smoke test for extension startup, not infra generation. Either update the comments to match, or add an actual azd infra synth call to exercise the importer pipeline end-to-end.