feat(eap): create deletion allocation policies for eap_items

[onewland]

No description provided.

[volokluev]

what happens to the materialized views? do deletes get processed on them as well?

[onewland]

what happens to the materialized views? do deletes get processed on them as well?

I think the way we use them today materialized views copy data to tables, and don't store the data themselves. Open to being corrected if I'm wrong. Looking at a random production storage nodde I see the following list of tables:

default.eap_item_co_occurring_attrs_1_local 
default.eap_items_1_downsample_512_local 
default.eap_items_1_downsample_64_local 
default.eap_items_1_downsample_8_local 
default.eap_items_1_local 
default.eap_spans_2_local 
default.eap_trace_item_attrs_local 
default.items_attrs_1_local 
default.ourlogs_2_local 
default.ourlogs_3_local 
default.ourlogs_local 
default.spans_attributes_meta_local 
default.spans_num_attrs_3_local 
default.spans_str_attrs_3_local 
default.uptime_monitor_checks_local 
default.uptime_monitor_checks_v2_local 

Right now we do deletes on

default.eap_items_1_downsample_512_local 
default.eap_items_1_downsample_64_local 
default.eap_items_1_downsample_8_local 
default.eap_items_1_local 

as defined in the config below in this very file: https://github.com/getsentry/snuba/pull/7601/changes#diff-524c729096fb923b16e1dc38a9acb4a33edf5b328ac1e538767e97d9e4fd22efR147-R151

The dataset-specific (spans, ourlogs, uptime) stuff I assume is all deprecated which (by my estimation) leaves:

default.eap_item_co_occurring_attrs_1_local 
default.eap_trace_item_attrs_local 
default.items_attrs_1_local 

If we want to handle these, I think it's going to be follow-up work since part of why we can delete so trivially from the downsampled tables is that they share the exact same schema. But right now I haven't scoped them in