Reworked the send processing queue
- Every send process is handled in an own process taken from a thread pool. The cache time for these processes was infinite which resulted sometimes in getting thousands of pooled threads that just did nothing (depends on the config setting). Mainly not a big deal but under Linux the number of user processes is often limited and it was required to change user settings to deal with high load. Now the send processes are just cached for 30s and then deleted if they are idle.
- Changing the number of max outbound connections to a value lower than a value that was currently required leaded to problems, e.g. if you had 10 outbound connections and reduced this to 5 in the settings - even if 10 were required.
- If the number of max parallel outbound connections was low (e.g. < 10) and the server load was high it happened that messages were not sent out but were kept in waiting state - creating the send processes is not as fast as creating new send orders under heavy load and there was a missing synchronization in the queue processing
- Several server setting values are now limited to a max value, e.g. the number of outbound parallel connections is limited to 99999 which should be currently enough.
- All attached clients will be informed now via server push message if a serversetting/notification setting has been performed. This user feedback is important because there was no real feedback if changes really ocurred - and on the other side all clients need to be informed if a single client changed the configuration.