Unlimited api request functions (REPLACEMENT for #188)

[namtacs]

This is an improved replacement pr for #188. If this gets merged, #188 needs to be closed.

Right now, if you try to request more than 40 data entries from various functions with api requests, it won't work. This is fixed here by introducing api_iterative_data and api_iterative_simple which iteratively fetch data from a url until the end. These functions are moved to a separate file: commons.py This module is not imported from __init__ (not exposed). Now it also contains common headers for requests.

TASKS:

• [x] api_iterative_data
• [x] A simple wrapper for api_iterative_data
• [x] Rework all project functions and retain compatibility
• [x] Rework all studio functions and retain compatibility
• [ ] Adapt for new commits (since Apr 2)
• [ ] Better headers and cookies management
• [ ] Rework all user iterative functions and retain compatibility
• [ ] Rework get_cloud_logs
• [ ] Move some stuff to commons.py
• [ ] Adapt (and possibly expand) wiki

The PR FORMATS project.py, studio.py (idk why this whole project isn't formatted) with black. This can create incompatibilities for existing PRs but will MASSIVELY help in the future with diffs.

Other changes:

• Created commons.py
• Moved headers to commons.py
• fixed a bug where if the comments num % 40 comments and get_comment_replies fetch excess batches up to limit
• fixed typo in studio.host code

[namtacs]

@TimMcCool please review this approach and implementation

[BuStudios]

The new commons file also seems like a great idea.

[LIZARD-OFFICIAL]

should be merged alredy

[namtacs]

This is a WIP, and i can't make sure to develop it until @TimMcCool gives some feedback

[TimMcCool]

This looks like a great addition to scratchattach, I'll merge most of this with some small additions tomorrow. Sorry for the wait

[namtacs]

Do we need to split (to separate PRs)? WDYM "most of this"? Basically only user functions and get_cloud_logs are left to do. If you want a split, i would suggest this: PR 1: Commons.py and project, studio and user functions PR 2: Better headers and cookies management, Move some stuff to commons.py, Adapt wiki

[namtacs]

what about the weird "cachebust" url param?

[namtacs]

Btw this project has a lot of code smells and mistakes, can work on a pr to clear that up

[TimMcCool]

After looking over the code i decided to merge all of this. I added the cachebust parameter because I suspected Server-side Caching on some API endpoints. i know that there are some flaws in the library, thanks for improving it

[namtacs]

THIS IS NOT DONE