feat(node): Add ability to send cron monitor check ins

[AbhiPrasad]

Closes #8006

Sentry has a cron monitoring product! This PR adds cron monitoring support to the Node SDK, so you can use the SDK to easily monitor your cron jobs!

You can monitor your cron jobs by sending check-ins to Sentry whenever they start and stop! If you notice a cron hasn't checked in, or has not submitted a finish check-in, you know there is something wrong and you need to investigate!

Based on the work in #7996, we expose a top level API to send check ins to Sentry. Currently there is no hub level method to do this, that was done intentionally.

To send a check in to Sentry, simply use the captureCheckIn method exported from the SDK. First you must send an in_progress, checkin, then you can send one with status ok or error based on what happened with your cron job.

const Sentry = require('@sentry/node');

// ...

Sentry.captureCheckIn({
  // make sure this is the same slug as what you set up your
  // Sentry cron monitor with.
  monitorSlug: 'dailyEmail',
  status: 'in_progress',
});

const startTime = timeInSeconds();

runTask();

Sentry.captureCheckIn({
  monitorSlug: 'dailyEmail',
  status: 'ok',
  duration: timeInSeconds() - startTime,
});

You can also optionally add a monitor config so you can create a monitor automatically, without needing to go into Sentry and setting up a cron monitor.

Sentry.captureCheckIn(
  {
    monitorSlug: 'dailyEmail',
    status: 'in_progress',
  },
  {
    schedule: {
      type: 'crontab',
      value: '0 * * * *',
    },
    // 🇨🇦🫡
    timezone: 'Canada/Eastern',
  },
);

Added some basic unit tests, and validated sending in Sentry as well.

[cleptric]

In Python and PHP, we opted to use Sentry.captureEvent.
Not against the introduction of Sentry.captureCheckIn, but unified API something something, maybe 🙂

[AbhiPrasad]

captureEvent in the JS SDK also allows you to pass in hint, which I thought felt confusing in this context, so we decided to make this an explicit API.

Easy to understand - and means we don't further overload captureEvent. captureCheckIn -> just for monitors!

[lforst]

giga l: you can simply do as const instead of as SerializedCheckIn here. TS is only complaining because status is interpreted as string.

[AbhiPrasad]

Gonna keep this anyway because I prefer the explicitness of the type.

[lforst]

🫡

[AbhiPrasad]

wooo