Follow-up on HSEARCH-1375.

No need to be overly precise (we don't want a detailed failure context as in the FailureHandler), because we will still report the failures to the FailureHandler for more detailed reports.

The idea is really to allow the user thread to know that an operation it requested failed, and to act accordingly (revert a change, compensate in some way, ...).

Tests to add (maybe some are already there):

1. [DONE in HSEARCH-3735] Integration test in mapper with backend mock: automatic indexing strategies should propagate exceptions upon execute (flush if no transaction, commit otherwise) (except "queued")

2. [DONE in HSEARCH-3735] Integration test in mapper with backend mock: SearchIndexingPlan.execute() should propagate exceptions (except if the strategy is "queued")

3. [DONE in or before] Integration test in mapper with backend mock: SearchWorkspace operations should propagate exceptions

4. [TODO] Integration test in mapper with backend mock: the MassIndexer's start/startAndWait methods should throw an exception when any failure occurs during mass indexing, in any of the background threads. Ideally a failure in one thread should cancel the whole mass indexing. Also ideally, if there are multiple failures we should use Throwable.addSuppressed. It's fine if non-fatal failures (failure to index an entity) are reported to the FailureHandler, but they should trigger an exception at the end.

Related: HSEARCH-3726,