Implement tracking api usage

[FoxxMD]

Since configurations are arbitrary and api usage is dependent on how the config is built usage can be highly variable. Currently CM can only keep track of total api usage per bot by looking at api quota response from snoowrap -- could also count debug calls from snoowrap for more time-awareness but granularity would still be per bot.

It would be greatly advantageous to be able to break down api usage based on check/rule/filter/etc... for each configuration in each subreddit. This would allow insight into two things:

• generally, CM api usage for individual components (to find optimizations and bugs where usage can be reduced by re-use/caching)
• to help moderators gain insight into how they can better optimize their configs

To this end the goal would be to "tag" api calls from snoowrap:

• on oauthRequest invocation directly by extending/overriding the function on the client OR
• providing an enhanced debug log function to snoowrap that can automatically retrieve a tag within context -- which we can then aggregate using a listening on winston

To implement the context the only lead I have right now is thanks to @thislooksfun from here where they introduced me to AsyncLocalStorage built into node and cls-hooked.

This might be straightforward to implement:

• instantiate an asyncLocalStorage object that gets passed to the created snoowrap client and the Bot at creation.
• pass the object down the execution stack to each subreddit (manager), subredditresource, rule, etc... and wrap each level with known calls to snoowrap with a new run context.
  • Pass some meta info about the type of context??
• gather the unique info using either winston logger context or with an event emitter from snoowrap on oauthRequest
  • Should the snoowrap execution be responsible for passing meta info on the "level" or should we iterate through each event execution to find an object by id and get meta info from the object statically??
• at the end of the event lifecycle aggregate meta info and store, if requested

---

Some resources for AsyncLocalStorage

• https://blog.kuzzle.io/nodejs-14-asynclocalstorage-asynchronous-calls
• https://codeandpepper.com/asynclocalstorage-in-node-js/
• AsyncLocalStorage kills 97% of performance in an async environment nodejs/node#34493 (performance issues)
  • There is a large performance penalty for using ALS so should only enable it for explicit profiling