The reconfiguration feature allows us to change thread-local state of components running on the worker pool, e.g., the zmq output channels.

The reconfiguration process assumes that there is a valid ReconfigurationType and that the object of type T you want to reconfigure inherits from Reconfigurable class. The steps involved are as follows:

1. A reconfiguration is started from QueryManager::addReconfigurationTask and it is necessary to specify the reconfiguration type, the instance to reconfigure, and whether the caller thread has to wait until the reconfiguration is done.
2. Internally, the QueryManager will create special tasks that will follow alongside the data buffer, which will eventually be executed in a strict FIFO order by the worker threads.
3. The method T::reconfigure is called by every worker thread and the reconfiguration is carried out.
4. The last thread that calls T::reconfigure will also call T::postReconfigure.

Currently, we use the reconfiguration machinery to:

1. create zmq output channels on the NetworkSink.
2. destroy zmq output channels on the NetworkSink.
3. detroy a query execution plan that gets un-deployed.

Currently, the reconfiguration machinery works only on a single node setup. To have it multi-node, we shall issue multiple calls to `QueryManager::addReconfigurationTask` via RPC. However, this might lead to wrong results depending on the reconfiguration type. Future work will involve devising and implementing a distributed protocol (see Rhino) to execute distributed reconfigurations.