I noticed this in our logs:
```
[offering] DEBUG: ℹ️ No cached Offerings, fetching from network
[purchases] VERBOSE: Updating all caches
[offering] DEBUG: ℹ️ Offerings cache is stale, updating from network in foreground
[offering] DEBUG: ℹ️ Offerings cache is stale, updating from network in foreground
[network] DEBUG: ℹ️ Network operation 'GetOfferingsOperation' found with the same cache key 'GetOfferingsOpe...'. Skipping request.
[network] DEBUG: ℹ️ GetOfferingsOperation: Started
```
The double "updating from network" can be confusing, so this fixes it so
it's only logged if the request will actually be started. Also
added/updated our tests to verify the correct logs as well as caching
behavior.
### Changes:
- Created `CacheableNetworkOperationFactory` to abstract operation and
cache key creation
- Instead of always creating an operation, we create a factory first,
which pre-computes the cache key
- This cache key is used to determine if it's a cache hit, as well as
for the subsequently created operation
I'm still investigating a leak (#2105), and I suspect it's coming from
us creating and storing completion blocks, and those staying in memory
beyond the lifetime of the operation.
This refactor and performance improvement helps us avoid get more things
in memory than we need to.
See #2138 for how this is tested.
We don't actually need to share a single queue to synchronize all the callback caches.
This new implementation also avoids using the risky `DispatchQueue.sync`.
This also fixes potential issues because `cachedCallbacksByKey` was exposed, and it could have been read without synchronizing access with the queue. This is now impossible.
