ref(profiling): implement chunked profile candidate query for flamegraph

[viglia]

This PR introduces an optimized chunked querying strategy for profile flamegraphs that improves performance when querying large time ranges. Instead of querying the entire datetime range at once, the new approach splits queries into exponentially growing chunks, starting with smaller intervals and potentially finding sufficient data without needing to query the full range.

Key Changes:

• Added feature flag organizations:profiling-flamegraph-use-increased-chunks-query-strategy for gradual rollout
• Added configurable options for initial chunk size (12h default) and maximum chunk size (48h default)
• Implemented get_profile_candidates_from_transactions_v2() and get_profile_candidates_from_profiles_v2() methods with chunked querying logic
• Early termination when sufficient profile candidates are found, reducing unnecessary queries

[codecov]

Codecov Report

Attention: Patch coverage is 7.60870% with 85 lines in your changes missing coverage. Please review.

✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
src/sentry/profiles/flamegraph.py	4.49%	85 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #95873      +/-   ##
==========================================
+ Coverage   86.49%   87.68%   +1.18%     
==========================================
  Files       10532    10583      +51     
  Lines      608735   610037    +1302     
  Branches    23950    23950              
==========================================
+ Hits       526530   534900    +8370     
+ Misses      81912    74844    -7068     
  Partials      293      293              

[Zylphrex]

I'm not fully convinced the profiling-flamegraph-always-use-direct-chunks branch will work as intended but I'm open to giving it a try and iterate.

[Zylphrex]

1. I don't remember how well we dedupe profile chunks so this might result in misleading flamegraphs
2. I'm not fully convinced this condition is enough in higher throughput situations. Though most of the time, the problem we're trying to resolve by directly looking at chunks is in low throughput situations so it may be okay.

[viglia]

1. we don't dedupe in vroom so, if we were to send a duplicate in the list it would be used twice for the aggregation, but here we prevent that by keeping track of seen_chunks. So, if we fall in this branch, we'll still check that set and only add chunks that were not previously added and avoid adding duplicates.
2. agree. I'm mainly worried about:

• lower throughput situations
• still keeping the max number of chunks/profiles <= max_profiles

Anyway as you mentioned in another comment, we can give it a try to see how it works and later iterate to improve it.