MBExchange на использование rwmutex.

циклов for( auto ...) и т.п.

- переименовал в MySQLInterface
- Упростил, убрал лишние функции
- добавил класс MySQLResult

Глобальное переименование uniset --> uniset2, libUniSet --> libUniSet2. Подготовка к возможности одновременной установки двух версий в одну систему.

Configuration: исправил ошибку со static переменными (конфигураций может быть много..а это не учитывалось).

Т.к. не может быть больше одного активатор-а на "процесс", использовал шаблон "Singlton" для UniSetActivator. Теперь его можно создать только так: .. UniSetActivator* act = UniSetActivator::Instance(); ..

В целях оптимизации: ОТКАЗАЛСЯ от (так и не ставшей необходимой) идеи "alias" для "node", и соответственно избавился от необходимости передавать и работать в IOContoller(IONotifyController,ShraredMemory) с ПАРОЙ id,node НО nеперь стало НЕЛЬЗЯ на одном узле запустить "ДВА НАБОРА ОДИНАКОВЫХ ДАТЧИКОВ ОТЛИЧАЮЩИХСЯ ТОЛЬКО УЗЛОМ(node)".

(MBSlave): добавил обработку аргументов командной строки (и конф. файла) для --xxx-after-send-pause и --xxx-reply-timeout

(NotifyController): ввёл mutex-ы на списки заказчиков, исправил потенциальную ошибку приводящую к SEGFAULT при работе с заказом пороговых датчиков.. или к "deadlock" (если mutex не так ставить).

(IONotifyController): сделал защитный mutex на список заказчиков, т.к. при большом количестве потоков, происходил SEGFAULT.

Оптимизация: перешёл на deque вместо list, там где во основном, проход по списку или обавление в начало или конец очереди (буфер).

(SM): Оптимизация: 1) перевёл механизм аварийного следа с std::list на std::deque, т.к. у std::list - дорогой вызов size(), а так же, нам собственно требуется в основном работы с добавление и удаление в начало и конец буфера. Профайлер показал "выигрышь" в HistoryItem::add().

2) Заодно перевёл "активацию" с mutex, на atomic (хотя commoncpp,
всё-равно внутри для atomic использует pthread_mutex).

(Оптимизация): спорный способ: отказался от mutex, для "не критиной" переменной. Просто сделал её atomic.