Fix performance issue with potentially notifying users of stockout

Requisition single approve had a performance issue where the majority of the time would be spent in logic to determine if stockouts occurred and to notify editors of those stock cards (in stock management, submission of a stock event).

The short-term solution to this was to make the notification logic asynchronous. This may save time for the user, but it does not save time for the server, as the stock management service still has to do this processing, just in a different thread. We need to improve this notification logic (StockEventNotificationProcessor and StockoutNotifier). Profiling statements have been added to see performance and the issue is somewhere in the NOTIFY_STOCK_CARD_EDITORS (StockoutNotifier.notifyStockEditors) logic.

It is suspected that the call to reference data's supervisingUsers may be the bottleneck. https://openlmis.atlassian.net/browse/OLMIS-3472#icft=OLMIS-3472 is a task to create a performance test for this API.

Acceptance Criteria

• Add profiling statement to StockEventNotificationProcessor.callAllNotifications()

• Determine what is causing the bottleneck in StockoutNotifier.notifyStockEditors()

• Using stock management performance data (https://openlmis.atlassian.net/browse/OLMIS-3473#icft=OLMIS-3473), make sure the profiling statement created in acceptance criteria above runs in <500ms (will need to check in perftest Scalyr logs)