[Profiling UI, 9.0.0] Clean up unused ES fields that will be removed in 9.0.0

[miloszmarcinkowski]

Meta issue
Related PR in ES

Clean up ES fields in Universal Profiling UI that are planned to be removed in 9.0.0.

AC:

• [Profiling, 9.0.0] Remove unused fields from the stacktraces and flamegraph API:
  • stacktraces:
    • remove total_frames
    • (TBD) replace stack_trace_events with stack_traces.[key].count (values are different, the latter migth be missing some events)
  • flamegraph:
    • remove TotalCPU
    • (TBD) replace TotalSamples with selfCPU or CountInclusive[0] (there is difference in value TotalSamples != CountInclusive[0] (but selfCPU = CountInclusive[0])) (we didn't find alternative for replacement)
• [Profiling, 9.0.0] Remove backwards compatibility code in CO2 calculator
  • (TBD) how is it going to affect API? @UpdateForV9 annotation moving change to v10
• [Profiling, 9.0.0] Remove backwards compatibility code for host.arch
  • (TBD) how is it going to affect API? @UpdateForV9 annotation moving change to v10
• [Profiling, 9.0.0] Remove backwards compatibility for missing cloud.provider, cloud.region, host.type
  • (TBD) how is it going to affect API? @UpdateForV9 annotation
• Additional, not listed in meta issue:
  • replace aggregation_field query in GetStackTracesRequest @UpdateForV9 annotation @UpdateForV9 annotation
  • (TBD) renderLegacyXContent field @UpdateForV9 annotation (doesn't affect ES API)
• (TBD) Coordinate the process of removing ES fields so it can be tested against updated UI (making sure that nothing got broken)

The fields will be removed from ES once UI is ready.

[elasticmachine]

Pinging @elastic/obs-ux-infra_services-team (Team:obs-ux-infra_services)

[rockdaboot]

[Profiling, 9.0.0] Remove backwards compatibility code in CO2 calculator
(TBD) how is it going to affect API? @UpdateForV9 annotation

We have to keep this because older 8.x agents may still send the old values. And we try to make transition from 8.x to 9.x as smooth as possible for customers. Best mark this for V10 to be removed.

The effect for customers with 8.x data could be wrong calculated CO2 emission values.

[rockdaboot]

[Profiling, 9.0.0] Remove backwards compatibility code for host.arch
(TBD) how is it going to affect API? @UpdateForV9 annotation

Let's keep it, similar reasoning as before.

Though, we can drop the field from the profiling-hosts mapping. In 9.x it won't be written to it any more. But the read path (pre 8.14 fallback) should be left intact for old 8.x data (customer may update from 8.x to 9.x without removing data).

Thanks for raising this: The agent code needs to be amended for 9.x (throw out legacy compat code) 😄.

[rockdaboot]

[Profiling, 9.0.0] Remove backwards compatibility for missing cloud.provider, cloud.region, host.type

Let's keep it, similar reasoning as before (8.x data may still be present after upgrading).

[rockdaboot]

(TBD) renderLegacyXContent field

Addressed with elastic/elasticsearch#119770

[rockdaboot]

TotalSamples != CountInclusive[0]

This is often not true, see the description of #106593 under UPDATE.