Initial support for /account/verify API.

[BR-]

Some things that should happen before "full" support:

New API responses

For example, Account credentials not valid is now WebChangePasswordDialog.passwordError. Most error handling should be moved from the /char/list callback to the /account/verify callback. Currently, no errors are specifically checked for. If the rate limiter kicks in at the wrong time, it won't backoff. acceptTOS, doMigration, verifyage etc may need to be updated.

Caching

accessTokens are invalidated after the time limit specified in the API response (currently, about 15 days). They are also invalidated the next time /account/verify is called - for example, by another instance of muledump or by the exalt launcher. If the cache is right, it takes 1 API call per account. If it's disabled, it takes 2 API calls per account. If it's wrong, it takes 3 API calls per account. There should be an option to disable the cache, globally or per-account.

Rate limiting

Anecdotally, I haven't had any problems with 50 accounts using "Automatic (Throttled)" and no cache. Either that setting is 2+ times slower than the true rate limit, or the endpoints have separate rate limits. EDIT: Got a report of hitting the 5 minute backoff with more than 60 accounts.

OCL

The /account/verify call needs to have a correct clientToken to launch the client. This could be calculated by the OCL script during installation, and pasted by the user into muledump's OCL setup. My rewritten OCL has this code to calculate it:

    FileDelete, %A_Temp%\GetClientToken.ps1
    FileAppend,
(
$stringAsStream = [System.IO.MemoryStream]`:`:new()
$writer = [System.IO.StreamWriter]`:`:new($stringAsStream)
$writer.write("$(Get-CimInstance -ClassName Win32_BaseBoard | foreach {$_.SerialNumber})$(Get-CimInstance -ClassName Win32_BIOS | foreach {$_.SerialNumber})$(Get-CimInstance -ClassName Win32_OperatingSystem | foreach {$_.SerialNumber})")
$writer.Flush()
$stringAsStream.Position = 0
echo "$(Get-FileHash -InputStream $stringAsStream -Algorithm SHA1 | foreach {$_.Hash})".ToLower() > %A_Temp%\GetClientToken.txt
), %A_Temp%\GetClientToken.ps1
    RunWait, PowerShell.exe -ExecutionPolicy Bypass -Command %A_Temp%\GetClientToken.ps1,, Hide
    FileRead, clientToken, %A_Temp%\GetClientToken.txt

I also made a Unity "game" that copies SystemInfo.deviceUniqueIdentifier in case the above fails, but haven't tried to integrate it with OCL. (reference: https://stackoverflow.com/questions/55809274/how-do-i-get-same-hardware-id-as-in-unityengine-systeminfo-deviceuniqueidentifie/66187334#66187334) There's another endpoint to hit: POST /account/verifyAccessTokenClient takes clientToken and accessToken.

Other

Deca might appreciate it if we pass muleDump=true to /account/verify the same way we do to /char/list.

I'm not too sure what the realmAPI function does over $.ajax. We may want to update realmAPI to handle POST requests if the things it does are important for /account/verify

muledump-cors-adapter-firefox does not work with this endpoint for some reason. I haven't tried Chrome. I'm using this extension in the meantime: https://addons.mozilla.org/en-US/firefox/addon/cors-everywhere/ (making the adapter work is one of the things realmAPI does over $.ajax >_>)

[BR-]

I thought this may have been better as a draft, given it's missing a bunch of things, but on second thought a "mostly working" muledump may be better than a "completely broken" muledump.

[BR-]

I'm doing OCL on a different branch, accessToken-ocl. I'll merge it into this pull req after testing it (don't have au3 on this computer). It's based on the AHK scripts I posted to the discord: https://cdn.discordapp.com/attachments/380668991825248257/829178372466016276/ocl_exalt_v6.zip

[zackpollard]

Have been testing out both this and the potion storage PRs myself and all seems to be working nicely for normal mules. If I try to add my steam account however there is a bug with line 1077 of mule.js where it can't determine how many stats are maxed for a character as carrcl is undefined. When commenting this if statement out the steam account loads as expected. I'm unsure if this was an existing bug or something introduced with the new account changes however might be worth addressing it with a patch as this caused the steam accounts to completely fail to load currently. Thanks for the changes, keeping muledump alive!