Plan analysis: statements inside a procedure, function or cursor sub-plan now get findings (#4514)

[erikdarlingdata]

Fixes #4514
Part of #4511

Builds on #4551 (the depth limit bounds how deep these sub-plans can go); merge it first.

Why

ShowPlanParser has always read a statement's UdfPlans/StoredProcPlan — for an EXEC <procedure> plan, every statement actually lives there, because the EXEC statement itself carries no query plan of its own. Nothing downstream read those fields: PlanAnalyzer.Analyze, BenefitScorer.Score and ShowPlanParser.ComputeOperatorCosts all walked the outer batch's statements only, so a procedure or function body got no findings, no benefit scores and no operator costs — an EXEC <procedure> plan analyzed as one statement with nothing to say about the statements doing the actual work. A cursor statement's operation never even read the sub-plan XML at all, so a function called by a cursor's query lost its whole body silently.

Plans that a user opens or pastes are affected — the plan viewer's window and the MCP analyze_plan_xml tool. A cached plan read back from the store is unaffected, because its statements sit at the top level already.

What changes

• New PlanStatements.EnumerateAll: an explicit-stack walk (no recursion) that visits every statement in a plan, including the ones nested inside a stored procedure or UDF body, each nested body following the statement that owns it.
• PlanAnalyzer.Analyze, BenefitScorer.Score and ShowPlanParser.ComputeOperatorCosts now use this walk instead of the outer batch's statements only.
• ShowPlanParser's UDF/StoredProc sub-plan reader moved above the "no query plan" early return (an EXEC <procedure> statement always takes that return, since its plan lives entirely in the body) and was extracted into a shared ParseSubPlans helper, called from both the normal statement path and the StmtCursor branch — a cursor operation's statement never read this sub-plan XML at all before this change.
• ParsedPlan.AllMissingIndexes / AllWarnings, McpPlanAnalysisFormatter.BuildAnalysisResult (the analyze_plan_xml/analyze_query_plan/analyze_query_store_plan MCP tools), both apps' drill-down collectors (PgDrillDownCollector.Plans.cs, DrillDownCollector.Plans.cs) and the plan viewer's statement list (PlanViewerControl.xaml.cs) all switched to the shared walk, so a finding inside a procedure or function body now surfaces everywhere a finding on the outer statement already did.
• Not ported: PerformanceStudio's EnumerateAllWithContainer/StatementWithContainer (the module-path-per-statement form used by its desktop grid and severity-override consumer) — PM has no AnalyzerConfig/severity overrides, and no consumer here needs to label which module a statement came from, so EnumerateAll alone covers every PM consumer.
• Double counting: each statement is visited exactly once by the walk (proven by a pin below), so a sub-plan statement's findings are counted once, not once per consumer walking it and once again via a separate descent.

Mirrors erikdarlingdata/PerformanceStudio@74ad0e4, erikdarlingdata/PerformanceStudio@73ca692 (minus the severity-override/UI container piece, as above) and erikdarlingdata/PerformanceStudio@4d978b4.

Test plan

New Darling.Tests.PlanSync4514Tests (6 tests), through the product's own ShowPlanParser.Parse + PlanAnalyzer.Analyze (+ BenefitScorer.Score) path — no test calls PlanStatements.EnumerateAll as a stand-in for the wiring:

• a synthetic EXEC <procedure> plan whose StoredProc sub-plan has a statement with a Non-SARGable scan (upper([t].[a])=[@p]) — the finding exists on the nested statement, both directly and via EnumerateAll;

• the same shape through a UDF sub-plan;

• a StmtCursor operation statement carries its UDF sub-plan (proves the parser-side read, not just the walk);

• EnumerateAll visits every statement exactly once on a 3-level nest (procedure > procedure > UDF), in source order;

• a 500-deep procedure chain completes (no recursion in the traversal; A deeply nested plan overflows the stack in ShowPlanParser and ends the process that parses it #4512's depth limit bounds the parse that built the tree).

• Runtime RED on the pre-port code (the same facts in a standalone probe that walks StoredProcPlan/UdfPlans by hand, on Plan analysis: a deeply nested plan no longer crashes the process that parses it (#4512) #4551's branch): all 4 fail there, e.g. Assert.NotNull() Failure: Value is null, because the parser never read an EXEC statement's sub-plans. The same probe passes on this branch.

• Mutation, reverted: PlanAnalyzer.Analyze back on batch.Statements fails the procedure-body, UDF-body and traversal facts (Collection was empty).

• Run: every PlanSync* class plus the plan-analysis classes: 0 failed (the live-Postgres plan-tool class runs in CI). Lite.Tests builds.

• Compared with PerformanceStudio main: EnumerateAll is the same explicit-stack walk, yielding bodies in source order. PerformanceStudio later added an EnumerateAllWithContainer form for its own UI; PerformanceMonitor has no consumer for it, so it is not ported.

• Darling's stored advisories: PlanAdvisoryAggregator reads AllWarnings/AllMissingIndexes, which now include sub-plan statements. Cached plans from sys.dm_exec_query_plan do not nest sub-plans, so the plans Darling stores are unaffected; opened, pasted and analyze_plan_xml plans are the ones that gain findings.

CHANGELOG

SECTION: Fixed
ENTRY: - Plan analysis now looks inside a procedure, function or cursor body ([#4557]) - The plan viewer and the analyze_plan_xml MCP tool skipped every statement inside a stored procedure or user-defined function call, and a cursor's own sub-plan was never read at all. An EXEC <procedure> plan analyzed as a single statement with no findings, no cost, and no benefit score for the work actually happening in the body.
REF: [#4557]: #4557