server messages need to maintain a synched order or queue system

[simon-kyger]

right now there are two events a client can issue to the server.

move() and stop()

the reason for this is to limit the amount of messages sent to the server.

the problem after implementing this is that the server can sometimes process stop() faster than the last move() that was issued, therefore this is what it looks like on the client:

move() move() move() stop()

however, when the server gets these, it finishes in this order

move() move() stop() move()

the problem with this is that if stop doesn't get called last, and another move gets issued out to client, then the client doesn't know any better than to keep rendering move() even if the player isn't anymore.

we need some sort of queuing system so that the order the client shoots messages to the server that those are perserved in the same order and not run asynchronously.

[simon-kyger]

this would be a good one to work on together via paired programming @shane-holland

[simon-kyger]

Fixed in https://github.com/simon-kyger/zealotry/commit/d12cdd53cbf922e14137dacee207c628ae8ecd2a