feat: api route for best audio only

[SmilerRyan]

Mostly solves issues #707 and #708.

Adds an endpoint to directly get a link to the best available audio.
Tested with a YouTube Video and Instagram photo. Example Endpoint URLs:

http://localhost:9000/api/best_audio?url=https://www.youtube.com/watch?v=wcT7zgL6gug
http://localhost:9000/api/best_audio?url=https://www.threads.net/@soren.iverson/post/C8PdJ59pMLr

[wukko]

this is an extremely niche feature and will expose all cobalt instance ips. the implementation is also lowkey ridiculous

[SmilerRyan]

As far as I can tell, this does as much exposure to the IPs as the json endpoint does, as it just redirects the client to the url instead of displaying it in json. As for the implementation it is practically the same as the json one but requires no input and has predefined options set for ease of use.

[dumbmoron]

another problem is that this would also inadvertently allow anyone to very trivially launch a large-scale DDoS attack any cobalt instance - they can just embed a few of these urls in a webpage of their own as e.g. <img> tags, or use embed preview services (like on social media networks) to make basically infinite requests to any cobalt instance - which might be triggering some expensive operation like audio conversion

[SmilerRyan]

Thanks for pointing that out. Whilst I see your point there, can't the same not be done by a script making a post request, then having them all hit the generated URLs the same way? Either way they're still taking the bandwidth from the media endpoint directly, the generated media link isn't IP locked, which doesn't help either (so only one user needs to go the post request for the link to be active with many IP Addresses).

Rate limiting the actual IP server side rather than blocking potential open proxies like mine sounds like it would be more effective than not adding another way to output a link to the actual stream data in the /api/stream endpoint, as my intention with this endpoint is to simplify the process by avoiding the need for a separate API and to worry about potential spam or abuse POST requests from my side.

As all this is (and does) is relay GET requests to POST requests on the instance, and return the media in a more compatible way, so applications/bots/etc don't need to be programmed to know how to use the api and can just have a link that they can open that redirects to the media endpoint in the end.

To me, this still makes me think the /api/stream links should only work once to prevent spam, and many multiple downloads from it a minute could simply be timed out for a few minutes so they slow down. Perhaps 5 or so stream endpoint hits could trigger it.