[ENH] V1 → V2 API Migration - estimation procedures

[EmanAbdelhaleem]

Fixes #1622
Depends on #1576
Related to: #1575

Details

This PR implements EstimationProcedures resource, and refactor its existing functions

[codecov-commenter]

Codecov Report

❌ Patch coverage is 67.92453% with 17 lines in your changes missing coverage. Please review.
✅ Project coverage is 54.01%. Comparing base (8ff14eb) to head (ce1499d).

Files with missing lines	Patch %	Lines
...enml/estimation_procedures/estimation_procedure.py	57.14%	9 Missing ⚠️
openml/_api/resources/estimation_procedure.py	76.92%	6 Missing ⚠️
openml/evaluations/functions.py	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1604      +/-   ##
==========================================
+ Coverage   53.96%   54.01%   +0.04%     
==========================================
  Files          61       63       +2     
  Lines        5051     5076      +25     
==========================================
+ Hits         2726     2742      +16     
- Misses       2325     2334       +9     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[geetu040]

This looks great. The implementation is clean and nicely decoupled. The next step should be adding tests, but let's wait until we have a clearer roadmap for that.
Also, please update the PR description to follow this format:

Fixes #...
Depends on #1576
Related to #1575

[geetu040]

update with #1576 (comment)

[geetu040]

@EmanAbdelhaleem Thanks for the PR. Nicely done!
I have updated the PR to sync with latest changes in base PR.

@PGijsbers please review/merge.

[PGijsbers]

I had a closer look at the old code. Best I can tell list_estimation_procedures is never called nor is it actually public (or am I wrong?). The PR also keeps some code duplication that existed in the old style. I would refactor it as follows:

• remove the current list function and rename list_detailed to list. Going forward, the only way to access the estimation procedures is with all their metadata. It seems that besides the retention of metadata, the only difference is in how to assess that the server response is parseable, and I don't think those differences matter (especially since it looks like list_estimation_procedures isn't used).
• define an EstimationProcedure named tuple which has fields id, name, task_type_id, and type. Make the list function return that instead.
• in _get_estimation_procedure_list you can convert the named tuples with ._asdict()
• in list_estimation_procedures just map to the names of the returned values to keep the response identical

This makes sure that at this stage we already reduce duplicate code, and that in the future we easily refactor further to make use of the typed return values instead.

[PGijsbers]

Can you try again? It really shouldn't. If it does and you don't understand why or don't know how to best resolve it, please let us know.