Unable to calculate missing data in index when getting last issue update time returns null

Issue Summary

This is reproducible on Data Center: yes

Steps to Reproduce

Reproduces on instances with "Disable empty JQL queries" set to 'ON'.

See here for details on this setting.

Expected Results

When Jira tries to update the index with missing data it compares the last issue update time in the local index to the last update time in the issue version table. 

When Jira contains an uncorrupted index (local index during start-up time or index restored from snapshot) it should be able to successfully calculate the missing time range and update the local index.

INFO Re-indexing issues updated in the last [time-range]. (Note: it's an intentionally wider range)

Actual Results

The below warn message is logged in atlassian-jira.log file:

WARN [INDEX-FIXER] Could not calculate the duration of time where index recovery/catchup needs to be applied!

WARN [INDEX-FIXER] The duration of time where indices will be missing could not be calculated.  Any changes to issues made after the index being restored will not be added to the new index! You can run a background reindex to add missing issue changes to the index. 

Notes

In recent case with Jira 9.2 we see the problem in logging, as last index date is retrieved as NULL:

2022-09-09 12:18:03,093+0800 main INFO      [c.a.j.issue.index.DefaultIndexManager] Index consistency check finished. indexConsistent: true; timeToCheckIndexConsistency: 3924 ms
2022-09-09 12:18:09,344+0800 main ERROR      [c.a.jira.cluster.DefaultClusterManager] Current node: jira-node1. Unable to get latest issue index update time.
...
2022-09-09 12:18:40,287+0800 main INFO      [c.a.j.index.ha.DefaultIndexRecoveryManager] [INDEX-FIXER] Restoring index with 1128047 issues
2022-09-09 12:18:40,298+0800 main INFO      [c.a.j.index.ha.DefaultIndexRecoveryManager] [INDEX-FIXER] Restoring search indexes - 1% complete... [INDEX-FIXER] Replacing indexes

Workaround

Temporarily set "Disable empty JQL queries" option to 'OFF' when starting nodes in affected cluster.

Notes regarding the fix