Requires progress on #18782

Rationale: treating warnings as errors in CI is crucial to ensure that deprecation warnings from our dependencies are not ignored, and that we don't write self-warning code unintentionally.
However, in oldestdeps runs, the intended environment should be predictible and stable (requires #18782), so deprecation warning should not be treated as (incoming) breaking changes. I would argue that in these conditions, warnings are actually perfectly acceptable, especially considering that they might be triggered by and from all sorts of dependencies outside our direct control.
The alternative, and current way forward as I'm writing this (and #18782 is an on-going project), is to filter numerous warnings that are seen in oldestdeps CI, which isn't ideal by any account.
For instance, this is what has been blocking discussions around #18780
I'm opening this issue to formalize my proposition that the approach followed in #18780 should be temporary, merely a mean to facilitate a transition, but that the filters introduced there should ultimately be removed once #18782 is finalized.