feat(Innertube/HTTPClient): Add BotGuardManager and improve one-time context in HTTPClient

[Illusion137]

Both of my PR drafts #1244 and #1231, were both in need of a proper BotGuardManager and a way to set one-time-context for many YouTube Studio Web related things like eats. This PR hopefully removes the two different poor systems that I wrote previously with a better and cleaner interface.

Noteable Features

• BotGuardManager
  • getChallenge() gets a BotGuard challenge (either api or page based) and handles caching within the BotGuardManager instance.
  • run() gets a BotGuard challenge and solves it using a generic BotGuardSolver interface; has support for both raw attestation data and RunAttestationCommand
  • log() many attestation operations simply require /att/log, so this just calls run() and properly sends over the webResponse and such
  • handles ytcfg for challenges that may need it since from https://github.com/LuanRT/BgUtils/pull/44, some challenges are binded to ytcfg.EVENT_ID
• one-time-context in Actions and HTTPClient there is now a arg called one_time_context which is a partial of Context, which is used to set some context params for just a single call without modifying the session.

Testing
Added some commented out tests to main.test.ts that tests:

• getting a basic API challenge
• getting a page challenge
• getting a page challenge that rolls into an ENGAGEMENT_TYPE_UNBOUND challenge with a eacr_token since, based on the atn_page_url, is doesn't return a challenge, but rather just a eacr_token

[LuanRT]

Is eats a requirement? Wondering if we can skip having that.

[Illusion137]

I'm not sure if eats is really a requirement since from what I've seen, putting a general eats or even no eats at all still works, to me including eats is more of just for future prevention. Like for me, I think it's generally best to mimick YouTube the best that's possible if we can... but if you believe it shouldn't be there lmk and I'll remove it

Update:
eats exists in only 3 places:

• ytcfg.EATS (YouTube Studio only it seems) the initial eats
• /att/get response eats; which now becomes the most recent eats
• context.request.eats which is set to the most recent eats. YouTube Studio seems to have its own eatsService which might be a good idea to implement when I get back to YouTube Studio Web.

from this, even if it seems useless, the fact that it seems fairly tied to attestation makes me think it'd be a good idea to keep it just in case.

[Illusion137]

Although if we do decide to keep it, should we continue to let the users manage eats, or should there be a eats variable in session and let the library handle it whenever the client is WEB_CREATOR?

[Illusion137]

So, a little bit of research and changes...
Changes

• eats is now tied to Session and automatically managed without any input
• added more ENGAGEMENT_TYPEs
• decided to include the Studio attestation process since it falls under this
  • required more parsing and other shenanigans
• refactored the BotGuardSolver related types to be a bit better
• added some Context utils
• likely some other smaller things like some fixes

Notes
I was previously very misunderstood on how attestation worked with YouTube Studio Web (even if I was able to get sessionTokens before) so:
the ENGAGEMENT_TYPE_CREATOR_STUDIO_ACTION challenge seems to ignore its args like ids and such and just uses atr_challenge likely since the channel_id is embedded into the challenge itself .
when /security/get_web_reauth_url returns a plt that means that your cookies session is out of date.

attestationResponseData is from solving the initial unbound challenge (tied to the page eacr) with:

{
  c: challenge
  e: 'ENGAGEMENT_TYPE_VIDEO_UPLOAD' | 'ENGAGEMENT_TYPE_VIDEO_METADATA_UPDATE',
  ...ids
}

Overall I think it looks quite a bit more polished and complete, but I'll likely have to give it a couple of more lookovers...