Performance - Prevent redundant processing back to January 1st 1970 on every cron run

This module has a very nice UI and works well for monolingual implementations, however underneath the prettiness lies a very nasty issue as described in the issue summary that this patch will resolve.

Bumping this to Critical since it leads to increasing vulnerability to denial of service, also taxes servers unnecessarily and can lead to severe performance issues. Most people who experience this probably think that the problem is Drupal it'self, very hard to diagnose and troubleshoot especially for most people.

We should just fix the glitch to help others that may be still using this module.

still critical, until this is fixed, use the "Scheduled Transitions" module instead

Aside from lacking the dependency injection for this: \Drupal::state()->get('system.cron_last'); near parfect. The MR11 is satisfactory for me as-is.

please put a checkbox next to our names at the bottom of this issue and press save

@joseph.olstad I created the MR with the exact same changes you uploaded in a patch years ago. However, I had to change a few things:
- I fixed the proper DI in the class,
- With this change, we're now disabling the processing of older transitions than last cron run, I added a new test case for that
- During writing a test for this new behavior, I found out that in the patch you were using a timestamp in the SQL query for the lowest scheduled_transition_date.value but in the database that field contains a Y-m-d\TH:i:s formatted UTC timezoned date, so the patch by default didn't change the requested behavior the way we wanted it, so I modified the code to pass a formatted date to the query.
- this a backwards breaking change, so I'm thinking about if we should set this new 'lowest date of a state transition' thing into a setting instead. But again due to how this module was architected + with the performance issues you were experiencing indicate that this should be the default behavior to not break huge sites. So maybe we have no other choice than commit this really.

Automatically closed - issue fixed for 2 weeks with no activity.