[BUG] Automatic transition from GET to POST not working, when "nextpage" exceede character limit

[TheMonzel]

Describe the bug
When a "nextpage" URI exceeds the APIs string limitation for GET request, the API responds with a 404 error and throws an error.

To Reproduce
Steps to reproduce the behavior:

1. Use Get-AutotaskAPIResource (-Method GET) with a potentially long query
2. Ensure that a nextpage are loaded
3. Currently, string length is only validated on the initial call; not for every next-page
4. The API throws an 404 error message

Expected behavior

• The module should throw a valid error message.
• The module should use POST instead of GET-method

Current Workaround
Adding 100 characters to the initial string length. Not the optimal option, but at least a start.
See:

AutotaskAPI/Public/Get-AutotaskAPIResource.ps1

Line 87 in 7540459

#100 characters for Call of next page (Including "paging={"pageSize":500,"previousIds":[<ID>],"nextIds":[<ID>]}&" UTF-8 encoded)

and 7540459

Additional context
Possible solution/enhancements:

• Make POST default (in this case only forced Get-queries could run into this issue)
• Use POST request instead of GET; this detection is made before the do .. while loop. "Nextpage" string can only be validated inside this loop. Therefor the logic must be called from inside the loop.

[TheMonzel]

@KelvinTegelaar Follow up for #65
I can post a commit switch the default call from GET to POST. I guess, this will do the job for all existing use cases. This issue would only persist, when Get-AutotaskAPIResource -Method GET is used.