fix: use post for searchRuns/use accurate multitrial detection

[ashtonG]

Description

this fixes a few issues with the multitrial check for run actions

• when the selection grew too large, the resulting url triggered a 431 error. we're switching the method of the search runs endpoint to post in order to get around this.
• the multitrial check used the wrong method to check if a run was part of a search
• the warning shown if the multitrial check returned positive had incorrect copy

Test Plan

• navigate to the runs table
• select all runs in the current page
• select the move action
• the check should succeed and the notice should show that multitrial runs will be moved along with other runs in their search

Checklist

• Changes have been manually QA'd
• New features have been approved by the corresponding PM
• User-facing API changes have the "User-facing API Change" label
• Release notes have been added as a separate file under docs/release-notes/
  See Release Note for details.
• Licenses have been included for new code which was copied and/or modified from any external code

[codecov]

Codecov Report

Attention: Patch coverage is 85.71429% with 2 lines in your changes missing coverage. Please review.

Project coverage is 51.27%. Comparing base (f61cde3) to head (9dbc662).

Additional details and impacted files

@@                       Coverage Diff                       @@
##           feature/actions-flat-run-table    #9546   +/-   ##
===============================================================
  Coverage                           51.27%   51.27%           
===============================================================
  Files                                1252     1252           
  Lines                              152000   151993    -7     
  Branches                             3017     3017           
===============================================================
- Hits                                77937    77934    -3     
+ Misses                              73904    73900    -4     
  Partials                              159      159           

Flag	Coverage Δ
backend	43.89% <ø> (-0.01%)	⬇️
harness	72.80% <ø> (ø)
web	47.85% <85.71%> (+<0.01%)	⬆️

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

Files	Coverage Δ
...components/RunFilterInterstitialModalComponent.tsx	98.21% <100.00%> (ø)
...ct/src/components/RunMoveWarningModalComponent.tsx	98.18% <100.00%> (+0.03%)	⬆️
webui/react/src/services/apiConfig.ts	73.80% <60.00%> (+0.23%)	⬆️

... and 4 files with indirect coverage changes

[AmanuelAaron]

Backend LGTM

[AmanuelAaron]

I think we should run the perf test once to confirm that this is working. I think it should.

[ashtonG]

ran it -- needed to stringify the filter param. rerunning now.

[keita-determined]

can we fix the conflicts? i'll review it afterwards

[keita-determined]

i got this error on this branch. i deleted all DB and tested in on the incognito mode
Do i miss something?

[keita-determined]

qq: what does -2 mean in this context?

[ashtonG]

-2 returns empty results, leaving just the pagination.

[ashtonG]

@keita-determined fixed -- i did a little code golfing before committing which didn't work out.

[keita-determined]

working good with many experiments

---

out of scope: do we want it in the experiment table as well, or just flat run since we eventually remove the experiment table?

[ashtonG]

we do, but I want to bundle that work with leveraging some other things we can do to reduce the backend complexity now that the parameters don't have to be strings. here's the ticket: https://hpe-aiatscale.atlassian.net/browse/ET-602