Eliminate redundant DB calls in osquery detail query ingestion

[getvictor]

Goal

User story
As a Fleet server operator,
I want to eliminate redundant database calls during osquery detail query ingestion
so that I can reduce per-host check-in overhead and improve server scalability.

Changes

Product

• UI changes: No changes
• CLI (fleetctl) usage changes: No changes
• YAML changes: No changes
• REST API changes: No changes
• Fleet's agent (fleetd) changes: No changes
• Fleet server configuration changes: No changes
• Exposed, public API endpoint changes: No changes
• fleetdm.com changes: No changes
• GitOps mode UI changes: No changes
• GitOps generation changes: No changes
• Activity changes: No changes
• Permissions changes: No changes
• Changes to paid features or tiers: No changes
• My device and fleetdm.com/better changes: No changes
• Usage statistics: No changes
• Other reference documentation changes: No changes
• First draft of test plan added
• Once shipped, requester has been notified
• Once shipped, dogfooding issue has been filed

Engineering

• Test plan is finalized
• Contributor API changes: No changes
• Feature guide changes: No changes
• Database schema migrations: No changes
• Load testing: Should verify reduced DB call volume per host check-in under load
• Pre-QA load test: Recommended - this change directly affects the hottest code path (SubmitDistributedQueryResults)
• Load testing/osquery-perf improvements: No changes
• This is a premium only feature: No

Summary of engineering changes

Introduce a hostDetailQueryConfig struct that pre-loads all configuration needed during detail query ingestion (AppConfig, HostFeatures, TeamMDMConfig, conditional access status) once per request instead of once per detail query result.

Key changes:

• New hostDetailQueryConfig struct holds pre-loaded configuration
• New loadHostDetailQueryConfig() method loads all four config values once
• SubmitDistributedQueryResults loads config once before the results loop
• ingestQueryResults, directIngestDetailQuery, and ingestDetailQuery receive the struct instead of re-loading from the database
• The pre-loaded AppConfig is reused for post-loop processing (label recording, policy webhooks, deferred host save)
• detailQueriesForHost also uses the same loader for consistency

Impact for a host check-in with N detail query results:

Metric	Before	After
AppConfig lookups	~2N + 2	1
HostFeatures / TeamFeatures lookups	~2N	1
TeamMDMConfig lookups	~2N	1
ConditionalAccessMicrosoftGet lookups (uncached)	~2N	1
GetDetailQueries rebuilds	~2N	0 (in ingestion path)

Please read this issue carefully and understand it. Pay special attention to UI wireframes, especially "dev notes".

Risk assessment

• Requires load testing: User story has performance implications that require load testing.
• Risk level: Low
• Risk description: Change is internal refactoring of how configuration is loaded during query ingestion. No public API changes. All existing unit tests pass. The primary risk is a subtle behavioral difference if config changes mid-request, but this is actually desirable (consistent config within a single check-in).

Test plan

Core flow

• Verify that host detail query ingestion still works correctly after the change

API

• No public API changes; all changes are internal to SubmitDistributedQueryResults and its helpers

Permissions

• No permissions changes

Edge cases

• Host has no team assigned (nil TeamID paths in loadHostDetailQueryConfig)
• Conditional access is not configured (verify conditionalAccessMicrosoftEnabled defaults to false)

Related issues

• #35467 - Audit codebase for expensive database calls in hot paths
• #40660 - numa postmortem action item: improving the inefficient API endpoint
• #40662 - Inspect our API endpoint for optimal performance

Confirmation

1. Engineer: Added comment to user story confirming successful completion of test plan (include any special setup, test data, or configuration used during development/testing if applicable).
2. QA: Added comment to user story confirming successful completion of test plan.