Packet flood degrades server peformance

This is a three part issue.

1) When a client floods packets to the server (example, the keep alive packet) the server uses an excessive number of synchronizations on the inbound packet list. Disputed locks are not trivial and the main thread loses precious cycles when this is occurring. This is a non-issue if a ConcurrentLinkedQueue is used for the inbound packets, instead of a Collections.synchronized(ArrayList).

2) When a client floods packets to the server, the server continues to process (by calling packet.execute, or the equivalent) them longer than client stays connected. Both 'net' handlers have a field to track disconnections and it is appropriate to check this field when processing successive packets.

3) When a client is logging in, they may spam the packet 205, spawning a new thread for each successful packet. They do not need to be premium to trigger this exploit and it will yield itself to a DDOS (such that, it's an amplification as well as memory leak) very easily if a flag is not set when the first packet 205 comes inbound. The specifics of this exploit are the client has the time between the first packet 205 and when the first thread can get a failed response from authentication server to send as many packet 205 as possible. This also spams the console. Fixed as of 1.4.6

3.5) This attacks are even more effective because the disconnect flag in the login 'net' handler is not volatile. Non-issue as of fix for duplicate packet 205

2.5) These attack is even more effective because the disconnect flag in the normal 'net' handler is not used when performing other calculations, including duplicate quits.