feat: Check-In Upserts

[bitsandfoxes]

Using this would look like this

var id = SentrySdk.CaptureCheckIn("my_monitor", CheckInStatus.InProgress, configureMonitorOptions: options =>
{
    options.Interval("0 * * * *");
    // or
    options.Interval(1, MeasurementUnit.Duration.Day);

    options.FailureIssueThreshold = 3;
    options.MaxRuntime = TimeSpan.FromMinutes(5);
    options.Timezone = "America/Los_Angeles";
    options.Owner = "me@there.com";
});

I wish I could use TimeZoneInfo but Windows has its own thing going on and supports IANA Timezone IDs out of the box starting with .NET 6 (source)
Checking with the other SDKs I don't really see the reason to build our own timezone converter for .NET 5 and older if the user has to specify via string which timezone anyway.

[github-actions]

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against 4b28b64

[bruno-garcia]

var monitorConfig = SentryMonitorConfig.CreateCronMonitorConfig("0 * * * *");
monitorConfig.FailureIssueThreshold = 3;
monitorConfig.MaxRuntime = TimeSpan.FromMinutes(5);
monitorConfig.Timezone = TimeZoneInfo.FindSystemTimeZoneById("Pacific Standard Time");
monitorConfig.Owner = "me@there.com";

This reads like an old C# API and seems very ackward to me.
Are all those properties optional? Threshold, MaxRuntime, TimeZone? (also casing in C# for this is TimeZone as its two words, as seen on TimeZoneInfo above too. Please validate casing before locking in a new PR (as in, merging a PR))

Why do we need an email for owner? I imagine that's optional? Since we use the DSN the cron job gets tied to a project which has a team/owner already.

Consider what's required value, and what's optional.
Take what's required, on the first set of args. And follow by optional parameters.
Additionally you can consider an overloap that takes a full object.

But finally, my understanding of upset was that it would take the same API we use to make a normal check-in. Can we figure out interval through that? The key feature/ask here is that I don't need to create something upfront. It'll take a new check-in it'll create a monitor for it. Maybe it requires a few check-ins to figure out the interval this job is running at before it can start alerting if check-ins are failing. cc @gaprl does it do that by any chance?

If we need some full blown API to create the cron job, do we run that once each time the app starts? If so, should that be on SentrySdk.Init(o => o.Crons(interval, threshold, etc) ?

[jamescrosswell]

As we discussed, I think we need to add some more argument validation to ensure users can only configure crontab values that Sentry will accept but otherwise looking good.

[jamescrosswell]

Similar to the cronTab argument to the overload above, we should either check that the interval + unit here are consistent with the accepted values in the Sentry protocol. Again, although we need to serialize this as a string in order to communicate it to Sentry, internally we could have a more structured representation of this, if that made it easier for the user to express and for our SDK to validate.