Optimization needed (probably)

[Camelva]

Alright so, signatureTimestamp (sts) extractor from my PR #199 is very basic, and it needs further optimizations.

Main considerations:

1. It looks like non-encrypted songs (those without cipher but with plain url in formats) works perfectly fine if we didnt send signatureTimestamp.
2. Because of ^1, maybe parsing player config for each particular song isn't the most optimal solution? Though, we can understand this only after making youtubei/player request (and getting 403 after decoding cipher, lol).
3. Currently lib loads player config two times:
   3.1. once to get sts, and its being proceed for every song,
   3.2. and second time to get decipherOpts when song contains cipher.
4. As it seems, sts changes not very often, so it may be reasonable to store it in cache same as decipherOpts.

Small digression about current DecipherOperationsCache:
It stores operations with videoID as key, but operations are player specific, not video. So, operations from "player/4fbb4d5b/.../base.js" will always be the same. And it seems like all videos using player with same version.

Also, why exactly default cache expiration = 5 minutes?
Maybe we could store values (both sts and decipherOpts for long time? And for validation we may send small HEAD request after decoding url and check for response code: If its 403 - clear cache and start again

[corny]

1. This already happens, if format.URL != "", correct?
2. That's true. To get the player ID, we need to fetch https://youtube.com/embed/... for each video, correct?
3. In this case the player config should be cached too.
4. Agree

Do you suggest to use the cache for videos and players? We also need to remove entries from the cache after some time. Maybe we can use a LRU cache instead of 5 minutes? I don't know a reason why it is excatly 5 minutes.

[Julian-Chu]

DecipherOperationsCache is to solve #140 , no special reason with 5 min cache time , only to make it simple at that moment, if necessary just change it.