### Changes:
- `HTTPClient` has a new `X-Post-Params-Hash` request header
- Replaced `HTTPRequest.Method.post`'s `Encodable` value with a more
specific `HTTPRequestBody` (like `HTTPResponseBody`)
- `HTTPRequestBody` allows overriding `contentForSignature` (it defaults
to `[]`) which then `Signing` uses for the hash
- Fixed `LogInOperation` not passing the `VerificationResult` to the
result `CustomerInfo`. This is captured in unit and integration tests
now.
- Add support for signing `POST` requests in `Path.logIn` and
`Path.postReceiptData`
Depends on https://github.com/RevenueCat/khepri/pull/6246
This also refactors the implementation to be able to share the same
code.
This algorithm will be used for some of the components in the new
signatures.
Fixes [CSDK-622].
### Changes:
- Extracted `FileReader` to be able to use it in `ReceiptParser`
- Extracted `MockBundle` to be able to use it in `ReceiptParser`
- Added new `public` `ReceiptParser.fetchAndParseLocalReceipt()`, **only
to `ReceiptParser`** (this is not available through `RevenueCat`).
- Added tests for the new API
- Added new API to `ReceiptParserAPITester`
Initially I thought about moving `ReceiptFetcher` to the
`Receipt|Parser` target. Unfortunately that would require moving a whole
bunch of other dependencies (`OperationDispatcher`, etc, etc).
We have no easy way to create a third "Core" framework in which to place
these common dependencies, so that wouldn't be trivial.
This solution adds a much simpler version of `ReceiptFetcher` that
simply reads from `Bundle.appStoreReceiptURL`. As it's documented there,
under normal circumstances `SKReceiptRefreshRequest` is not required, so
this implementation should work for 99% of use cases, and so this way we
avoid increasing the.codebase complexity unnecessarily.
[CSDK-622]:
https://revenuecats.atlassian.net/browse/CSDK-622?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
Should fix#2198 and [SDKONCALL-200]. This is a big performance
optimization in time and memory, as we no longer need to convert the
entire receipt to `base64` and concatenate it to the string, which is
what was likely causing #2198.
This now uses `Data.hashString`, which avoids any data copies and
efficiently creates a hash with the receipt content.
Apart from the new tests for this property,
`BackendPostReceiptDataTests.testDoesntCacheForDifferentReceipts`
ensures that different receipts have different cache keys, and therefore
this new implementation still avoids collisions (other than the
extremely unlikely hash collisions).
[SDKONCALL-200]:
https://revenuecats.atlassian.net/browse/SDKONCALL-200?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
I noticed that the existing implementation was creating many copies of the string as it grows, which isn't very efficient.
The new implementation allocates the required size initially and writes to the same buffer inside the loop.
NachoSoto