RUM-3889 feat: send retry information with network requests

[ganeshnj]

What and why?

This PR is implementation of https://datadoghq.atlassian.net/wiki/spaces/RUMP/pages/3422683761/RFC+Retry+information+headers+and+query+string+params

How?

The gist of PR is, when we make a network request to upload data

• Inject retry_count and last_failure_status under ddtags query param
• Inject DD-IDEMPOTENCY-KEY header

Both retry_count and last_failure_status are available after the first request failure which is persisted in the uploader, and during the next request used to populate the query param.

Review checklist

• Feature or bugfix MUST have appropriate tests (unit, integration)
• Make sure each commit and the PR mention the Issue number or JIRA reference
• Add CHANGELOG entry for user facing changes

[ncreated]

The concept looks very good in overall 👌, but I left few notes on implementation details, some blocking. Let me know WDYT 🙂!

[ncreated]

change-request/ We have existing DatadogCore/Sources/Utils/Cryptography.swift which makes a better place for this function. Notably, the sha1() is only required for DatadogCore so it should belong to that module rather than DatadogInternal.

[ganeshnj]

I still think the method must be in its own file as we are not creating a global method but an extension to data but sure, this can be place next to Cryptography.swift.

[ganeshnj]

Had to move back to Internal because Core is not directly used in the features and adding sha1 is feature specific.

[ncreated]

change-request/ This file duplicates a lot of elements from existing URLRequestBuilder. The URLRequestBuilder is more comprehensive and structured way of building URLRequests within the SDK and we should prefer it over adding free-form helper functions if possible.

If we can't use URLRequestBuilder, we shouldn't be at least exposing these functions to other features through DatadogInternal. They should belong to DatadogCore otherwise this can end-up in diverging from centralized URLRequestBuilder and spreading custom request formatting code among the codebase.

Ideally tho, because URLRequestBuilder implements both headers and query items formatting, the new elements introduced in this PR could be somehow part of it. I can imagine the FeatureRequestBuilder protocol to return builder instance rather than already-baked request. This way DatadogCore could configure additional elements using the builder and only the call the final build() to produce URLRequest.

// cc @maxep as co-author of this foundation

[ganeshnj]

fair call, let me see how we can fit all this together.

[ganeshnj]

Ok, now we are fully using the FeatureRequestBuilder although this leaks injection of retry headers to each request builders which I don't like but that's the only cleaner way to reuse what we have.

At some point we might want to change the signature of the request builder to return a builder type which can further be updated without a lot of mutations of Swift types.