enhance: Reduce unnecessary goroutines during search

[bigsheeper]

Since SQ thread pool is present in cgo.Search, allocating goroutines at the segments level for concurrency is unnecessary. Simply use the thread pool directly at the segments level to avoid extra goroutines.

issue: #27456

[sre-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: bigsheeper
To complete the pull request process, please assign czs007 after the PR has been reviewed.
You can assign the PR to them by writing /assign @czs007 in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• internal/querynodev2/segments/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[mergify]

@bigsheeper ut workflow job failed, comment rerun ut can trigger the job again.

[codecov]

Codecov Report

Attention: Patch coverage is 85.96491% with 8 lines in your changes are missing coverage. Please review.

Project coverage is 81.74%. Comparing base (83ce352) to head (ecf5b75).
Report is 12 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #32703      +/-   ##
==========================================
- Coverage   81.77%   81.74%   -0.03%     
==========================================
  Files        1001     1002       +1     
  Lines      125359   125435      +76     
==========================================
+ Hits       102517   102542      +25     
- Misses      18956    18997      +41     
- Partials     3886     3896      +10     

Files	Coverage Δ
internal/querynodev2/segments/segment.go	66.87% <100.00%> (-0.21%)	⬇️
internal/querynodev2/segments/search.go	63.63% <76.92%> (+0.96%)	⬆️
internal/querynodev2/segments/retrieve.go	79.66% <76.19%> (+0.66%)	⬆️

... and 34 files with indirect coverage changes

[congqixia]

It's recommended to leave SQPool usage in segment to make sure all search/query operations using cgo pool in case of future misuse out side

[bigsheeper]

you mean that I should create a new pool for this, right?

[congqixia]

nope. I suggested that the SQPool usage shall remain in segment.Search/Query method. search/queryOnSegment shall using a simple for-loop is good enough

[bigsheeper]

got it, make sense

[bigsheeper]

With the solution of keeping SQPool usage within the segment, we need to return the future objects to the out side scope. However, when I attempted to make this modification, the code became more convoluted and monitoring metric was disrupted. Taking all this into consideration, I would suggest keeping with the current approach.
BTW, the SQPool is already being used out side (in RetrieveByOffsets).
@congqixia

[mergify]

@bigsheeper E2e jenkins job failed, comment /run-cpu-e2e can trigger the job again.

[mergify]

@bigsheeper ut workflow job failed, comment rerun ut can trigger the job again.