Fix parallel segment reload race on IndexLoadingConfig tier; add IndexLoadingConfig.copy() to avoid per-segment ZK fetches

[rsrkpatwari1234]

Problem

When multiple segments were reloaded in parallel (reloadAllSegments / batched reloadSegments), all tasks shared a single IndexLoadingConfig from one fetchIndexLoadingConfig() call. Each reload path calls setSegmentTier(...) (and related updates) on that shared instance, so concurrent tasks could overwrite each other’s tier. With tier overrides in table config, that could apply the wrong preprocessing / loading settings (#18164).

Fix

• BaseTableDataManager.reloadSegments: Renamed to reloadSegmentDataManagersInParallel and calls fetchIndexLoadingConfig() once per batch, then for each parallel task pass indexLoadingConfigTemplate.copy() into reloadSegment, so every segment gets its own config for tier and other per-segment mutation.
• IndexLoadingConfig.copy(): New method that builds a new IndexLoadingConfig with the same instance / table / schema references and tableDataDir, without copying segmentTier (each copy starts clean, like a fresh fetch). This keeps correctness while avoiding N repeated ZK reads (one fetch + N light copies instead of N fetches).

Tests

IndexLoadingConfigTest: Asserts copy shares TableConfig / Schema, matches tableDataDir, does not inherit segmentTier from the template, and that tier changes on the copy do not affect the original.

Fixes #18164

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 63.23%. Comparing base (7e10a36) to head (f8e2537).

Additional details and impacted files

@@             Coverage Diff              @@
##             master   #18174      +/-   ##
============================================
+ Coverage     63.18%   63.23%   +0.05%     
  Complexity     1616     1616              
============================================
  Files          3214     3214              
  Lines        195838   195842       +4     
  Branches      30251    30251              
============================================
+ Hits         123734   123836     +102     
+ Misses        62236    62105     -131     
- Partials       9868     9901      +33     

Flag	Coverage Δ
custom-integration1	100.00% <ø> (ø)
integration	100.00% <ø> (ø)
integration1	100.00% <ø> (ø)
integration2	0.00% <ø> (ø)
java-11	63.19% <100.00%> (+0.07%)	⬆️
java-21	63.13% <100.00%> (-0.03%)	⬇️
temurin	63.23% <100.00%> (+0.05%)	⬆️
unittests	63.22% <100.00%> (+0.05%)	⬆️
unittests1	55.43% <100.00%> (+0.04%)	⬆️
unittests2	34.82% <42.85%> (+0.04%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[rsrkpatwari1234]

Requesting review on this. Integration test failure seems unrelated to this PR -

java.lang.AssertionError: [ExactlyOnce] Transaction markers were not propagated within 120s; committed records are not visible to read_committed consumers. read_committed=0, read_uncommitted=153636
	at org.apache.pinot.integration.tests.ExactlyOnceKafkaRealtimeClusterIntegrationTest.waitForCommittedRecordsVisible(ExactlyOnceKafkaRealtimeClusterIntegrationTest.java:181)