fix(settings): specify VALID_RETENTION_DAYS for self-hosted

[aldy505]

Fixes getsentry/self-hosted#3421

I saw from the rust_snuba code, that we have this:

snuba/rust_snuba/src/processors/utils.rs

Lines 10 to 20 in acfbe9a

	let mut retention_days = value.unwrap_or(config.default_retention_days);
	if !config.valid_retention_days.contains(&retention_days) {
	if retention_days <= config.lower_retention_days {
	retention_days = config.lower_retention_days;
	} else {
	retention_days = config.default_retention_days;
	}
	}
	retention_days

But if we follow the default value, it will always defaults to 30. Whereas not everyone on the self-hosted instance uses value greater than 30. My own instance is set to 14.

snuba/snuba/settings/__init__.py

Line 251 in acfbe9a

LOWER_RETENTION_DAYS = 30

Legal Boilerplate

Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.

[BYK]

/gcbrun

[untitaker]

can we move the fetching of env vars into settings/__init__.py? I don't think there's a reason to expose those env vars for self-hosted only.

[aldy505]

can we move the fetching of env vars into settings/__init__.py? I don't think there's a reason to expose those env vars for self-hosted only.

@untitaker Will it break your production servers? If you don't need to change anything on your prod configs, then I'll do that.

[aldy505]

Also, can we merge this before the next release window (which is tomorrow)?

[untitaker]

let's just keep it for now as that seems to be an established pattern.