RUMM-2203 Use unique data directory for each instance of the SDK

[ncreated]

What and why?

📦 With this PR, each instance of DatadogCore will use a different directory for managing its data.

This is a step forward towards V2 architecture, where we're going to support multiple SDK instances. Each instance of the SDK needs to persist data in different locations.

This is the content of /Library/Caches/ when using two instances of DatadogCore:

How?

Each DatadogCore now accepts a "core directory". I introduced a separate CoreDirectory type that wraps Directory - this is to enforce type safety at configuration level and to avoid passing wrong directory by mistake.

The CoreDirectory creates the folder structure for SDK and its Features. It uses a hash function (sha256) for computing the folder name that is unique for given instance of the SDK:

let directoryName = sha256("\(clientToken)\(site)")

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

Custom CI job configuration (optional)

• Run unit tests
• Run integration tests
• Run smoke tests

[ncreated]

@maxep When writing this comment I realised that we cannot ship V1's data deprecation as part of V2 SDK. Because V1 uses single folder, the V2 SDK cannot know if particular com.datadoghq.<feature> folder corresponds to this or foreign installation. Think: a vendor SDK installed in an app where both use Datadog SDK but vendor uses V2 and app is on V1.

What we can do instead is having this deprecated paths work the same as authorised and unauthorized - meaning they will be applied relatively to the SDK "core directory". It implies no need for this configuration now, but we could eventually leverage it later. We could remove this setup for now, or keep it empty.

WDYT?

[maxep]

a vendor SDK installed in an app where both use Datadog SDK but vendor uses V2 and app is on V1

If both versions mismatch, the app won't be able to install the vendor framework as a dependency, except if the vendor is manually linking the Datadog SDK as a static lib, which should be discouraged IMO. The app would have to upgrade to v2 or use a previous version of the vendor SDK to match the version. So I wouldn't consider this use case.

Now, multiple instances of the v2 SDK will perform the same operation on the deprecated v1 directories, so I wonder if this is the right place for v1 depreciation 🤔 We can consider this as a temporary measure and eventually remove this deprecated when we consider good adoption for v2 (which can take time..)

[ncreated]

👍 Right, I think it's fair to assume there will be a single version of the SDK even if multiple instances are enabled.

Indeed, there's a room for improvement around deprecation logic. Because it requires more refactoring in different parts of the codebase, I created RUMM-2312 to focus solely on data deprecation logic. For now, I'll keep it as it is - capable of removing global SDK folders, without ensuring the logic is ran only once.

[maxep]

Nice work with the hash for identifying core instances 👍
LGTM ✅