Possible Race Conditions during ContentPack Installation

## Expected Behavior
During installation of a ContentPack, all runtime/in memory structures should be consistently created/recreated.

## Current Behavior
If you have a ContentPack that creates Data Adapters, Caches and Lookup Tables in one step, the asynchronous updates of these structures can fail due to possible race conditions.
During development of the Watchlist features/migration script, one of the problems have been mitigated by moving the code that loads the lookup tables to a given cache right next to the recreation code of said LUTs.
Each save of a Data Adapter/Cache/Lookup-Table posts its own Update-Event on the server bus, those are asynchronously processed by a scheduler so you neither know when one of the in-memory structures have been replaced or also the order/sequence those tasks take place. For the Watchlist migration script, the main problem even was, that one event overtook the other during processing so that necessary structures were missing in MongoDB during creation of a cache.

see #11413

## Possible Solution
Fire all update events for Data Adapters/Caches/LUTs after the whole CP was saved to MongoDB and not fire the event after each save for a type.
Also, maybe make the init/update code in LookupTableService synchronous instead of the current async installation so that you know that structures have been consistently replaced before initializing dependent objects.

## Steps to Reproduce (for bugs)

1.
2.
3.
4.

## Context

## Your Environment

* Graylog Version:
* Java Version:
* Elasticsearch Version:
* MongoDB Version:
* Operating System:
* Browser version: