Certain URI-based protocols not properly handling URI encoding

[helpimnotdrowning]

Summary of the bug:
I originally discovered this when trying to play a video in SMPlayer using the mpv backend, though this can be reproduced with ff* tools.

When trying to open a file with a URI-encoded URI, ffmpeg will fail to read the file. From ​https://github.com/mpv-player/mpv/issues/10103 , I was pointed to avformat being the issue (though I wasn't able to find this person's issue here).

How to reproduce:
In my case, URIs are coming encoded from KDE's Dolphin trying to open a remote (sftp) file in SMPlayer that contained a "#" in its path. In ffprobe, the error is

$ ffprobe 'sftp://helpimnotdrowning@192.168.1.243:22/mnt/W/URUHA RUSHIA CH - ARCHIVE/Rushia Ch. 潤羽るしあ/20191130 - 【%23潤羽るしあ3D】潤羽るし あ3Dお披露目です！【ホロライブ】/20191130 - 【%23潤羽るしあ3D】潤羽るしあ3Dお披露目です！【ホロライブ】 [aBGaFFIP9bs].mkv'
[...]
[libssh @ 0x7fb370001900] Error opening sftp file: SFTP server: No such file
sftp://helpimnotdrowning@192.168.1.243:22/mnt/W/URUHA RUSHIA CH - ARCHIVE/Rushia Ch. 潤羽るしあ/20191130 - 【%23潤羽るしあ3D】潤羽るしあ3Dお披露目です！【ホロライブ】/20191130 - 【%23潤羽るしあ3D】潤羽るしあ3Dお披露目です！【ホロライブ】 [aBGaFFIP9bs].mkv: Input/output error

When I reference a local file with the file: protocol, this issue also persists.

When the "%23"s are manually switched out with "#", ffprobe will correctly read the file.

$ ffprobe 'sftp://helpimnotdrowning@192.168.1.243:22/mnt/W/URUHA RUSHIA CH - ARCHIVE/Rushia Ch. 潤羽るしあ/20191130 - 【#潤羽るしあ3D】潤羽るしあ3Dお披露目です！【ホロライブ】/20191130 - 【#潤羽るしあ3D】潤羽るしあ3Dお披露目です！【ホロライブ】 [aBGaFFIP9bs].mkv'
[...]
Input #0, matroska,webm, from 'sftp://helpi[...]

This occurs under ffmpeg 5.1.6 for Debian Stable and a gyan.dev ffmpeg 7 build for Windows.

Though I am not one to read through RFCs, the linked mpv issue mentions that URIs using reserved characters (like the #) should always percent-encode/URI encode those characters (​https://github.com/mpv-player/mpv/issues/10103#issuecomment-1101352451 ), of which avformat seems to break.

[Cigaes]

The paths for FFmpeg are mostly not URLs, even though they are sometimes called URLs in the documentation. Only a handful of protocols are treated as URLs correctly.