[Chore](profile) attach always true counter to column predicate

[BiteTheDDDDt]

What problem does this PR solve?

attach always true counter to column predicate

This pull request introduces enhancements to the predicate profiling functionality in the OLAP scan and filtering pipeline. The main change is the addition and propagation of a new counter, predicate_always_true_rows_counter, which allows for tracking the number of rows for which a predicate is always true. This improves the granularity of predicate statistics and profiling, aiding in performance analysis and debugging.

Predicate Profiling Enhancements:

• Added a new counter, predicate_always_true_rows_counter, to ColumnValueRange, ColumnPredicate, and FilterOlapParam for tracking rows where predicates are always true. This includes updates to their constructors and member variables. [1] [2] [3] [4]
• Updated methods and logic to propagate the new counter through predicate initialization and attachment, including changes in constructor calls, method parameters, and assignment logic. [1] [2] [3] [4] [5] [6] [7] [8] [9]

Integration with Predicate Initialization:

• Modified predicate initialization in TabletReader::_init_conditions_param to pass and utilize the new always_true_rows_counter for both normal and bloom filter predicates. [1] [2]
• Updated scan operator logic to ensure the new counter is attached during predicate normalization in the pipeline execution path.

Runtime Filter Wrapper Support:

• Added accessor for predicate_always_true_rows_counter in VRuntimeFilterWrapper to expose the new profiling metric for vectorized runtime filters.

Check List (For Author)

• Test

  • Regression test
  • Unit Test
  • Manual test (add detailed scripts or steps below)
  • No need to test or manual test. Explain why:
    • This is a refactor/code format and no logic has been changed.
    • Previous test can cover this change.
    • No code files have been changed.
    • Other reason

• Behavior changed:

  • No.
  • Yes.

• Does this need documentation?

  • No.
  • Yes.

Check List (For Reviewer who merge this PR)

• Confirm the release note
• Confirm test cases
• Confirm document
• Add branch pick label

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?

[BiteTheDDDDt]

run buildall

[BiteTheDDDDt]

run buildall