Prevent race condition between audit Elasticsearch indexation and index reset

See NXP-19721 and duplicate NXP-22168 for examples.

What can happen is that:

• The index is created as soon as a write is performed in Elasticsearch, typically with a POST request for an audit log entry.
• The index reset process is launched concurrently.

In this case the index reset performed by ElasticSearchAdmin#dropAndInitIndex(String indexName) tests if the index exists, it doesn't. Concurrently the AuditBulker wants to write an entry and creates the index. Then, the reset tries to create the index and crashes because it already exists.

This would happen because of events fired by the CoreFeature initialization for which we wouldn't actually wait for because of NXP-19721. Yet with the fix it can still happen if we don't wait for the AuditBulker.

A solution would be to signal that the index is not available when resetting an index. There is the ElasticSearchAdminImpl#indexInitDone flag but it probably doesn't work with concurrency because it is not volatile.
We should try to mark it as volatile and make the audit indexation check if ElasticSearchComponent#isReady as it is done when indexing a document.