This commit adds the basis for the intergration of a security manager into BungeeCord. The goal of the security manager is to prevent plugins from doing potentially dangerous or otherwise undesirable behaviour that may damage the stability of Bungee itself or pose a risk to the user's server.
One common theme in some Bungee plugins, especially those which were written in the very early days, is using Threads and ExecutorServices for scheduling purposes. Not only is this inefficient as there is no use of the thread caching features provided by the scheduler, it is also difficult to track who created which thread. Additionally creating threads not managed by the BungeeCord scheduler poses issues for when|if a plugin reload system is implemented, as these threads cannot be appropriately cleaned up and may continue to leak class references or perhaps even continue executing.
At this stage the SecurityManager is set to warn of prohibited actions, but not block them. For some plugins using external APIs, where usage of an ExecutorService is unavoidable, we have included an Unsafe interface to the scheduler which allows direct access to the underlying ExecutorService, or potentially a compatability wrapper.
This will attempt to make use of Netty's EpollEventLoopGroup and Epoll(Server)SocketChannel when on Linux and the native libraries load correctly. It should bring a large increase in performance and hopefully reliability. Big thanks to the @netty team for implementing this and @normanmaurer for some tips on the support detection.
Feedback is appreciated.
Currently, passing a null favicon String to the ServerPing(Protocol, Players, String, String) constructor causes a NPE. However, passing a null `Favicon` object to the corresponding constructor does not cause one. Setting the favicon String using the setFavicon(String) method doesn't cause a NPE either.
Therefore, the NPE thrown by the constructor is inconsistent and should be avoided. Please find a sample NPE here: http://newpaste.md-5.net/pmtqjc8vl (Note the `null` favicon)
This PR changes the documented (unintended?) behaviour by adding a null check before passing the favicon String to the alternative `Favicon` object constructor. This makes the constructor consistent with the other one and the `setFavicon(String)` method. This also adds compatibility for old (made before Favicon API) plugins passing `null` favicon Strings (and expecting no favicon to be displayed instead of a NPE).
Thanks!
