Debugging deprecated/renamed PSR-0 classes being requested

This is covered in the WP 6.2 Field guide post, and in the post about the upgrade of the requests library that you found the deprecation warning in.

If your plugin or theme uses Requests directly and supports a wider range of WordPress versions, you may need to conditionally declare the REQUESTS_SILENCE_PSR0_DEPRECATIONS constant as true to silence deprecation notices about the old PSR-0 class names. You should upgrade your code as soon as WordPress 6.2 becomes the minimum WordPress version for your plugin or theme.

If your code uses the WP_HTTP APIs then no changes are needed, this only affects code that directly uses the raw Requests API.

For fixing it:

If your plugin or theme uses Requests directly, and only supports the latest version of WordPress, you should update your code to use the namespaced names. For example, to perform a request with a try-catch using the namespaced names:

// Old: Perform a request with a try-catch in Requests 1.x.
try {
    $response = Requests::request( $url, $headers, $data, $type, $options );
} catch ( Requests_Exception $e ) {
    return new WP_Error( 'http_request_failed', $e->getMessage() );
}
 
// New: Perform a request with a try-catch in Requests 2.x.
try {
    $response = WpOrg\Requests\Requests::request( $url, $headers, $data, $type, $options );
} catch ( WpOrg\Requests\Exception $e ) {
    return new WP_Error( 'http_request_failed', $e->getMessage() );
}

The most compatible way to fix this, and prevent it ever happening again, is to use the WP_HTTP API and WP functions such as wp_remote_post etc