Support check-ins for Quartz

[adinauer]

📜 Description

Add a JobListener for automatically reporting check-ins for scheduled Quartz jobs.

💡 Motivation and Context

Quartz support for #2875

💚 How did you test it?

Manually with samples

📝 Checklist

• I reviewed the submitted code.
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.

🔮 Next steps

[github-actions]

	Fails
🚫	Please consider adding a changelog entry for the next release.

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

Instructions and example for changelog

Please add an entry to CHANGELOG.md to the "Unreleased" section. Make sure the entry includes this PR's number.

Example:

## Unreleased

- Support check-ins for Quartz ([#2940](https://github.com/getsentry/sentry-java/pull/2940))

If none of the above apply, you can opt out of this check by adding #skip-changelog to the PR description.

Generated by 🚫 dangerJS against 600a58c

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	347.16 ms	384.06 ms	36.90 ms
Size	1.72 MiB	2.29 MiB	575.93 KiB

Previous results on branch: feat/crons-quartz

Startup times

Revision	Plain	With Sentry	Diff
20bea77	333.96 ms	460.00 ms	126.04 ms
1cdfac5	375.94 ms	456.28 ms	80.35 ms

App size

Revision	Plain	With Sentry	Diff
20bea77	1.72 MiB	2.29 MiB	575.93 KiB
1cdfac5	1.72 MiB	2.29 MiB	575.93 KiB

[codecov]

Codecov Report

Patch has no changes to coverable lines.

❗ Current head f4fb1dd differs from pull request most recent head 600a58c. Consider uploading reports for the commit 600a58c to get more accurate results

📢 Thoughts on this report? Let us know!.

[lbloder]

I think we should change the way we handle the monitor config, as described in the comment. Otherwise LGTM

[lbloder]

Shouldn't we use context.getTrigger() instead?
Maybe we'd also have to add some part of the trigger to the monitor slug.
Because the we way it is now, if we have two or more triggers for the job it will always take the info of the last CronTrigger in the triggersOfJob list.

Small example (add to SentryDemoApplication in jakarta):

  @Bean
  public JobDetailFactoryBean jobDetail() {
    JobDetailFactoryBean jobDetailFactory = new JobDetailFactoryBean();
    jobDetailFactory.setName("hello there 123");
    jobDetailFactory.setJobClass(SampleJob.class);
    jobDetailFactory.setDescription("Invoke Sample Job service...");
    jobDetailFactory.setDurability(true);
    return jobDetailFactory;
  }

  @Bean
  public SimpleTriggerFactoryBean trigger(JobDetail job) {
    SimpleTriggerFactoryBean trigger = new SimpleTriggerFactoryBean();
    trigger.setJobDetail(job);
    trigger.setRepeatInterval(10000);
    trigger.setRepeatCount(SimpleTrigger.REPEAT_INDEFINITELY);
    return trigger;
  }

    @Bean
    public CronTriggerFactoryBean trigger2(JobDetail job) {
      CronTriggerFactoryBean trigger = new CronTriggerFactoryBean();
      trigger.setJobDetail(job);
      trigger.setCronExpression("0/20 * * ? * *");
      return trigger;
    }

[adinauer]

At the moment there's no support for multiple triggers in Sentry. I opted for a more consistent approach by getting the list of triggers so we don't update the monitor config on every invocation.

[adinauer]

We no longer send the schedule and also get the slug from the job data map. We'll document how to handle multiple triggers.