WIP: Introduce item_configs on ProjectConfig

[loewenheim]

This adds a field item_configs on the ProjectConfig that is eventually intended to subsume both retention and trimming configs for logs, spans, trace metrics, and trace attachments (and possibly further configuration we may introduce). Currently, the logic is set up such that retention configs are pulled from the new item_configs if it's defined and from retentions otherwise. This means that so long as the new field isn't set, no behavior changes.

I adapted a number of integration tests to validate this logic.

Questions:

• Is this something we even want to do?
• Should the fallback logic for retentions be reversed, i.e. should we prefer retentions when it's set?
• Is the structure sensible (RetentionConfig nested in an ItemConfig)?
• Are the names sensible?

[jjbayer]

Is this something we even want to do?

The retention config is closely tied to the trace item produced on the kafka topic, but trimming happens much earlier, during normalization, so to me it feels wrong to group it with storage-specific concerns. Feel free to change my mind though.

[Dav1dde]

The retention config is closely tied to the trace item produced on the kafka topic, but trimming happens much earlier, during normalization, so to me it feels wrong to group it with storage-specific concerns. Feel free to change my mind though.

I am not sure either, there is also a practical concern. Trimming config is public and we (may) want to propagate that to managed Relays, retention config does not need to be propagated (although it could be).

[loewenheim]

Discussed offline: we're not moving forward with this; we'll rather keep configuration for trimming, retention, &c. as separate top-level fields on the project config.