…actions

See #2107. We still don't know what caused that, but it leads to degraded performance (mildly reduced by #2115).
To advice of that, in case users are wondering why the app might potentially take excessive CPU usage, I added this warning.

…actions

See #2107. We still don't know what caused that, but it leads to degraded performance (mildly reduced by #2115).
To advice of that, in case users are wondering why the app might potentially take excessive CPU usage, I added this warning.

…ottle errors (#2146)

Fixes #2116.

Depends on #2134, #2144, #2145.

We've known that, especially for sandbox accounts with lots of
purchases, the SDK can get flooded with a lot of transactions to process
at once.
I've been making some improvements for this (like #2115).

Another consequence of this behavior, is that we can end up failing due
to `StoreKit` throttling us (see #2116):

> 2022-12-03 12:31:58.670892+0100 app[673:61074]
<SKReceiptRefreshRequest: 0x283edc860>: Finished refreshing receipt with
error: Error Domain=ASDErrorDomain Code=603 "Request throttled"
UserInfo={NSLocalizedFailureReason=Unified receipt is valid and current,
NSLocalizedDescription=Request throttled, AMSServerErrorCode=0}

This change avoids that by skipping the refresh if less than 2 seconds
have elapsed. I chose 2 to make this a low-ish risk change, with a huge
benefit for multiple semi-concurrent requests coming from a big
transaction queue.

…actions (#2117)

See #2107. We still don't know what caused that, but it leads to
degraded performance (mildly reduced by #2115). To advice of that, in
case users are wondering why the app might potentially take excessive
CPU usage, I added this warning.