Ratelimit queue manager

[k3n]

Genesis of idea here, copied with slight modifications here for posterity (see follow-on comment there though for addt'l info).

The problem I initially sought to solve is "How do we give meaningful feedback to users when dealing with multiple API requests, which may run into the ratelimit?", and @Geo1088's proposed improvement of unifying the ratelimiting functionality in #248 would greatly increase our ability to implement something consistent across TB.

---

Brainstorming here, so beware this isn't a fully-formed idea, but I was thinking of the benefits that this unified rate-limiting feature would bring us via providing a central location to inject additional behaviors.

For instance, I'd presume whatever form this code takes will have some sort of queue, and would know the status of each item in that queue. Given such, we could expose what we know in a meaningful manner within some place like the TB context menu or menu bar.

Maybe a badge or some other UI affordance with the current count of outstanding requests, which could additionally be decorated to communicate that the rate limit has been reached and requests are queued, like the number (or background) turns red, the badge bounces, or something to that effect.

Maybe hovering this badge would give more info, e.g.:

6/10 requests processed (11s until next request)

Taking this wacky idea further, clicking the badge -- and perhaps, auto-opening when a mass-request action is initiated, e.g. multi-selected modqueue items -- could open a pop-up of some sort that'd list each request and their status.

Indulge me...

Key: ✔ complete ❌ failed (completed w/errors, may not need) ◌ (animated) in progress ○ todo

 _______________________________________________________________
|  TB Request Manager                                           |
|---------------------------------------------------------------|
|     Progress (2/6 complete, 2 in progress):                   |
|     __________________________________________                |
|    |=============                             |               |
|     ------------------------------------------                |
|                                                               |
|  ✔  Remove: "Title of the 1st post in the queue" by u/one     |
|  ✔  Remove: "Title of the 2nd post" by u/two                  |
|  ◌  Spam: "Title of the 3rd post" by u/three                  |
|  ◌  Spam: "Title of 4th post" by u/four                       |
|  ○  Remove: "Title of 5th post" by u/five                     |
|  ○  Spam: "Title of 6th post" by u/six                        |
|                         ____________     ____________         |
|                        | Cancel All |   |     OK     |        |
|                         ------------     ------------         |
 ---------------------------------------------------------------

The proposed UI implementations are just for conversation fodder to give us a starting point.

[k3n]

Re: @creesch's comment about needing more info to show what's mocked above, the actual titles/usernames may not be particularly beneficial (and may not apply to other forms of mutli-requests like usernotes pruning).

An alternative might be to simply categorize the request per the API endpoint, and maybe include the thing ID (or whatever that is in the URL e.g. fep4og). .