Index optimization is triggered for every change above 4000 even when an optimization is already in progress

I was running tests on JIRA with ~1 000 000 issues, where index optimization time started to be non-trivial (in minutes)

It turned out that when the jira.index.max.reindexes limit got exceeded the index optimization operation was started for every change even though index optimization was already started (and not finished) by the previous change.

As a result I ended up with 34 concurrent index optimizations (taking 2 hours to finish), which totally saturated JIRA.

Workaround - set jira.index.max.reindexes to 0 and rely on nightly optimization.

What it should look like: don't schedule index optimization if one is already in progress.