fix: add read-path stub creation for unsymbolized profiles

[marcsanmi]

Fixes #4383

Problem

After commit ac947a1 removed stub creation, unsymbolized OTLP profiles were skipped when symbolizer is disabled. If the symbolizer is enabled, symbolizer itself will populate those stubs.

Fix

Create stubs at query time. When symbolizer is disabled and blocks have
unsymbolized profiles, generate stubs functions like "libjvm.so 0xcafebabe".

Why read-path? Preserves raw profiles in storage, allowing future symbolization when users toggle the symbolizer on.

⚠️ The fix is only added to v2. Adding it to v1 would require either:

• Checking every profile for unsymbolized locations on every query (performance overhead), or
• Adding equivalent to block metadata checking to v1's querier to avoid checking every profile at read time.

Considerations

We could also try adding those stubs at ingest time. However, if symbolizer is enabled, the system would skip stub functions preventing real symbolization unless we re-process data or implement stub detection logic

[oleg-kozlyuk-grafana]

Check #4470 - this case may be already covered

[marcsanmi]

Check #4470 - this case may be already covered

#4470 fixed the HasFunctions flag so blocks are properly tagged as unsymbolized. This PR adds the stub creation logic that runs when symbolizer is disabled. Both changes were needed, but I'd say address slightly different things.

[simonswine]

LGTM

[simonswine]

LGTM

[korniltsev-grafanista]

I've run the branch, but I see no stubs

[korniltsev-grafanista]

does this only fix pprof query? and not tree query?

[marcsanmi]

does this only fix pprof query? and not tree query?

Yes, you're right. It needs to be applied to tree as well to update the flamegraph. It'll just work for pprof (export)... Going to update it

[marcsanmi]

Closing this PR since this needs to be done at the query backend level since we skip the locations there; so we don't have them available in the query frontend. Since this would imply a bigger change, I'm closing this and creating an issue to address it in the future.

Closing this PR since this needs to be done at the query backend level, where we skip the locations; so we don't have them available in the query frontend. Since this would imply a bigger change, I'm closing this and creating an issue to properly address it.