Add ability to schedule Event Definitions with a cron expression

[kingzacko1]

Adds support for cron scheduling of Filter & Aggregation event definitions. Its just a plain textbox for the cron expression. Frontend will need to work their magic if we want a GUI-driven cron expression generator in product. In lieu of a full-blown cron expression generator, I've added a /validate/cron_expression API endpoint to allow the frontend an easy way to validate the current expression in the textbox. It validates the expression and if successful returns a description of the cron expression so users can confirm that is how they wish to schedule the event.

NOTE: After testing this PR if you want to keep all the event defintions you were testing with you should change all event definitions back to not using cron scheduling and then disable them. This should cleanup any cron related fields in the DB when switching back to other branches without these changes. If you don't care to keep the event definitions, just delete them.

Description

• Add a cron_expression and cron_timezone field to AggregationEventProcessorConfig to support cron scheduling
  
• Fixes CronJobSchedule.calculateNextTime to truly calculate next time instead of next future time
  • Reporting seems to rely on this method returning the next future time. Will need to refactor to actually use a method that returns that.
• Moves logic describing event definition scheduling to the backend to take advantage of the CronDescriptor.describe method. It's a little wonky sometimes, but better than trying to handle on the frontend.
  

Motivation and Context

Graylog2/graylog-plugin-enterprise#6598
#19365
Also possibly:
#12364
Graylog2/support#46

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Refactoring (non-breaking change)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.

[bernd]

A few backend-related notes.

[bernd]

When does #nextTime(trigger, to) return an empty Optional? The method's Javadoc says that the trigger shouldn't fire anymore if it returns an empty Optional.

[kingzacko1]

In this context, it would theoretically return an empty Optional only if the cron was specified to run for a given year/set of years and the event had run for the last time in the last year.

    @Test
    public void emptyNextTimeCron() {
        final JobTriggerDto trigger = JobTriggerDto.builderWithClock(clock)
                .jobDefinitionId("abc-123")
                .jobDefinitionType("event-processor-execution-v1")
                .schedule(CronJobSchedule.builder()
                        .cronExpression("0 0 * ? * * 2024")
                        .build())
                .build();

        final DateTime nye2024 = DateTime.parse("2024-12-31T23:00:00.000Z");
        final Optional<DateTime> nextTime = strategies.nextTime(trigger, nye2024);

        assertThat(nextTime).isEmpty();
    }

In which case, the nextTime value would also be empty because the trigger's lastNextTime would have to be after the last to time. So the event would not run.

[danotorrey]

@kingzacko1 I ran through this today and did some testing. It's looking awesome! It worked well with my tests and jobs always seemed to execute per the cron schedule. The frontend is working well too in terms of validating the expression on save, and the validate API endpoint was super-helpful too. I'll do a bit more testing on the job catch up logic and will report back when done.

[danotorrey]

@kingzacko1 LGTM and tests successfully. Frontend editing of events with and without cron schedules works successfully, and cron schedules execute successfully.

[ryan-carroll-graylog]

Looks great and functionality wise all tests successfully!

Had one nit about possible error UI massaging, but otherwise this looks good to go to me!

[zeeklop]

The modification tested successfully. Thank you @kingzacko1 for getting the front end done as well. The one thing that is odd for me, is the placement of the checkbox and the fields.

So when the user selects the checkbox to set a cron schedule, the fields change above the checkbox. I believe the checkbox should be placed on top of the fields. It would match better the vertical flow of the form.

[zeeklop]

This looks slick! nice work! tested successfully. I notice one thing, pressing the sync button disables the sync schedule, is that behavior correct?

Sorry. this was meant for Simon's PR. Got my tabs crossed

[zeeklop]

Tested successfully. Thank you Zack!

[danotorrey]

LGTM and tests successfully with the latest.