Make login/authentication (a bit) more state-automata friendly

[Omikhleia]

Clients that want to automate the login/playing steps (e.g. bots) or to request the user for action (e.g. graphical client with popups etc.) need to keep track of the session state (Disconnected > Connected > Authenticated > Playing). While the successful situation works well (due to the 'login', 'playing', 'logout' and 'quit' socket events), the error scenarios are a bit trickie to manager. Currently, there are a number of 'ouput' events that may be sent (welcome text, help, etc.) at these stages, alongside errors.

My solution so far was to react when the error messages occur. These are displayed in red, but relying on color does not seem very robust. It's rather doable looking at the string patterns.

Pseudo client-code:

onOuput(msg) {
  addLineToTextView(msg)

  if (currentState !== PLAYING) {
    if ((msg.search(/Invalid/) !== -1) ||
        (msg.search(/Passwords did not match/) !== -1) ||
        (msg.search(/Sorry/) !== -1) ||
        (msg.search(/You have no character/) !== -1))
      // Bots will want to exit gracefully.
      // Graphical UI may want to display the error but re-prompt the previous actions
      doSomeStateTransition('error')
    } else if ( (msg.search(/Character created/) !== -1)) {
      // Graphical UI may want to automatically send a 'play' command, or re-prompt a 
      // "play or create character" request, etc.
      doSomeStateTransition('created')
    }
  }
}

This does work fairly well, despite not being very clean... It may also stand as it is, but depending on how far #148 goes in allowing customization, however, relying on hard coded game-engine strings might even break some day.

One simple possible solution is to add 'created' and 'failure' socket events, sent by the game engine itself just after the usual error outputs (for the latter) or the character creation (for the former).

Pros:

• It's easy
• It does not event break the existing client, since it does not listen to these new event.

Cons:

• Isn't it still kind of an ad-hoc solution?
• It adds extra socket messages.

For the record, the 'error' cases in question are the following (matched by less patterns above):

• Invalid username or password.
• Invalid command
• Invalid selection
• Sorry, that username is taken.
• Sorry, that name is invalid.
• Sorry, a character by that name already exists.
• Passwords did not match.
• Bad password. (Heh! Not caught above - but this unlikely occurs normally)

Plus one 'success' case:

• Character created