Crons: Allow checkins to be associated to an environment

[evanpurkhiser]

This should enable checkins to provide a environment string as part of the checkin payload.

This means that we will now associate a checkin to a MonitorEnvironment, we should dual write denormalized checkin details to the monitor environment table.

• For now this association should be optional until we can backfill all the environments for ALL EXISTING CHECKINS.

• We will need to call get_or_create during the checkin to ensure the environment exists.

• The default environment should likely be production.

• We will need to associate that environment in the MonitorEnvironment if we haven't already.

• We should write the checkin status into the monitor environment as well as continue to write to the monitor.

• You cannot update the environment of an already created checkin (this should be an error if it is different)

In a follow up we will start reading status from the monitor environment, see #42788

[NOTE!!]: We do not want this to be part of the API docs yet, that will be done in #45025

[evanpurkhiser]

The default environment should likely be production.

@wedamija and myself were looking at this with this query

select se.name, count(*)
from sentry_monitor sm 
inner join sentry_environmentproject sep on sep.project_id = sm.project_id
join sentry_environment se on se.id = sep.environment_id
where sm.status not in (1,2,3)
group by se.name
order by count(*) desc

Which tells us what the common env names are for the projects with monitors.

Looks like the empty string is common followed by production and prod. I am guessing we’ll want to go with production since that’s what the SDKs will send by default? But I don’t know that we do that anywhere else in sentry, since the get_or_create actually uses the empty string.

name	count
	2483
production	2264
prod	1118
staging	695
development	659
dev	526
local	489