Fix some service.game_notify concurrency problems (closes #978).

The assertion that was asserting that no listeners modifies the game
during service notifications was removed, because it didn't take
asynchronous execution into account.

Also due to the asynchronous nature of notifications, it was possible that
some events were silently 'dropped' and not dispatched to the listeners.
This has been corrected, and a test case added.

For more background and a more detailed discussion see:

http://tickets.farsides.com/issues/978
Make table discard game that takes to long to be created (closes #985).

When a new game from the table is ready, the table starts a timer
which fires after a predefined delay (currently 1 minute) and checks
whether the game was moved into 'invitation' state by that time yet.
If it hasn't, it "rolls back" the state of the table, discarding the game,
pointing back to the previous game as the current game of the table,
while choosing a new next_owner.

There is still one problem that crossed my mind, which is that if
a discarded game ever makes it into 'invitation' state, it should
be completely dettached from the table, and moved into a brand new
table; or the table state could get seriously corrupt if two games
were played and tracked under the same table simoultaneously.
Merge branch 'master' of git://gitorious.org/cardstories-mtyaka/cardstories
Notify players about next games and owner changes (refs #987, #985).

The table plugin modifications done previously for #985 have proved to be
buggy in subtle ways, so I had to rewrite them. I am much more satisfied with
the current approach than the previous one.

Instead of setting a new game as the current game, and later discarding it,
don't set a new game as the current game of the table until it is ready,
instead store all "next" games as pending games of the table and only "promote"
one of them to the current game when it reaches the 'invitation' state.

There are three types of dialogs that a player can see:

- A player has joined a pending game, and has now been chosen to be the next owner.
  He is prompted to create a new game.
- A player has joined a pending game, but another player created another playable game
  which is now the next game of the table. He is prompted to join it.
- Owner of a game in pending state is slow, and another player beats him at creating
  the next game. He is prompted to join the other game.

I was having problems with JS tests in IE - they were flip-flopping with random phantom
errors, which is something we have seen before. After struggling with that for a while,
I discovered the reason was some jqDock code that was running asynchronously, and kept
running past the end of associated test, messing with the state of other tests.

In order to get around this (to wait until jqDock has finished doing its thing
before going on to the next test), the $.cardstories.create function now returns
a deferred object in cases where we need them for testing.
Spin pending games into their own tables (closes #994).

When one of the pending games is promoted to become the next
game of the table, the remaining pending games are spun off
into their own tables.

I noticed there was a problem with a modal overlay blocking
access to the sentence box in create_write_sentence state,
so that was fix as well.
Add an option to turn animations off (refs #998).

If the parameter 'animations' with value 'off' is present in the url,
the animations are "skipped", allowing one to play the game much faster
which can be useful when doing manual tests.

This is achieved by turning jQuery animations off by setting $.fx.off = true
in combination with modifying calls to $.cardstories.delay and
$.cardstories.animationTimeout to always invoke the underlying function with
delay set to zero.

The function $.cardstories.animationTimeout was added. When animations are on,
it works exactly like $.cardstories.setTimeout, but when animations are off,
it always calls setTimeout with a zero delay. A new function was needed because
we use $.cardstories.setTimeout for tasks other than animations, where we can't
just change the delay to 0 and expect things to still work.

Another minor change I slipped into this commit is changing the timeout
after a failed ajax call retries. It was previously set to 100 ms. It was me
who initially chose that value, but to be honest, I have no idea why I thought
100 ms would be a good value. I bumped it up to 1 second so that when something
bad happens, the server isn't showered with neverending retry requests.
One second might still be to short, but I didn't want to change things drastically yet.
Fix a bug where concurrent state calls would trigger multiple owner changes (refs #998).

The update_next_owner_id() method is asynchronous. With my initial naive code,
multiple concurrent calls to update_next_owner_id() would trigger multiple next_owner_id
changes (and by extension, call self.touch(), causing the poll to return multiple times).
This happened in real life where when a game was completed, all connected players issued
'state' requests simoultaneously, each of the 'state' requests in turn invoking
update_next_owner_id(), causing the next_owner_id to rapidly cycle between players before
it settled down.

My second approach was to ignore any calls to update_next_owner_id() if an invokation
of update_next_owner_id() was already in progress. This approach was better and prevented,
the situation described above, but it had one flaw: Sometimes update_next_owner_id() is
called because the facts upon which we rely to decide which player to pick as
the next owner have changed, such as when a player disconnects and therefore isn't
a suitable candidate for next owner anymore. Since my second approach was ignoring
calls to update_next_owner_id() if one was already in progress, it could ignore events
such as a player disconnecting.

My final approach is to store the deferred object that update_next_owner_id() is waiting
upon, and if another call to update_next_owner_id() is made before the first one has finished,
the exising deferred is cancelled, and a new one started, with fresh facts taken into accout.
Always show current value of next_owner_id (refs #998).

Don't try to priorotise players that already created (pending) games.
This is simpler (and from a player's perspective probably doesn't make
too much difference), and more importantly, fixes the problem where
user wouldn't be notified when table started pointing at him as the
next owner.

See comments on the issue for more info:

http://tickets.farsides.com/issues/998

Also fixed in this commit was a problem where previous_game_id wasn't
set when creating the next game from inside a pending game.
Fix a number of problems related to tables (refs #998).

The on_tab_closed hook was removed - we aren't using monitoring
of tab open/close events to detect player's presence anymore.
This was done for simplicity and because we are using timeouts
to cycle among potential next owner now, I believe this to be
less of an issue.

The other important change was delaying the time when pending games
are detached from the current table. Previously they were detached too
soon, now they are only detached if they reach 'invitation' state, or
if the current game goes into 'complete' state.

More info can be found in the comments on the ticket:

http://tickets.farsides.com/issues/998
Close next_owner/next_game dialogs when they are no longer needed (refs #998).

The next_owner/next_game dialog would previously be shown forever, even after
switching tabs or refreshing the page.

This commit implements some checks to see if the dialogs should be kept opened:

- for the owner_change dialog, the dialog should only be kept open until next_game doesn't
  exist yet.

- for the game_ready dialog, the dialog should only be kept open until the player
  opens the tab with the next game.
Fix further problems with tables and next_owner_ids (closes #998).

After doing more thorough manual testing, I discovered two other problems:

1) Players who already joined one of the pending games wouldn't be given
   a chance to be the next owner.

The reason was the the update_next_owner_id() method would check the player's
opened tabs to see if player keeps the current game opened in a tab.
The reason was that when a player joins the pending game, the tab with the
previous game is automatically closed (and replaced with the pending game's tab).

To fix this problem I only removed the check for an opened tab. I believe that since
we now have timeouts, this shouldn't be too much of a problem anymore.
It would be possible to make the table plugin smarter by also checking for opened
pending games, but I decided to try the simplest thing first, and improve on it
in the future if it turns out to be neccessary.

While players who joined a pending games should be given a chance to be the
next owner, the owners of pending games shouldn't, so I had to add a simple filter
to filter out pending game owners when selecting suitable next owners.

2) When a player who joined a pending game was notified that he was the next
   owner, the text that says "<player name> took to long to create the next game",
   had the current player's name in the <player name> placeholder, while it should
   have been the name of the pending game owner that the current player has joined.
Delete runme.sh - that was commited by accident.
Rename badly named functions (refs #919).

Taking comments on #919 into account, I decided to rename functions like this:

- get_opened_tabs_from_args() -> get_open_tabs()
- get_opened_tabs() -> get_tabs_for_player()
- remove_tab() -> close_tab_action()

I learned today that I have been using the word "opened" when I should
have been using "open", so I fixed my poor grammar through the codebase :)
Merge branch 'master' of git://gitorious.org/~antoviaque/cardstories/antoviaques-cardstories
Add django-paypal to requirements.txt.

Unfortunately, they don't provide an actual package, so I had to refer
to the git repository, but did refer to a specific version - the tree
that is the current master.
Remove the -e flag before django-paypal package in requirements.txt.

It's supposed to be used when you want to hack on the package, as it
checks out the code into a 'src' folder under the current dir.
We don't really want that, just install django-paypal into the site-packages dir.

For some reason, without the -e flag, I had to specify the protocol
as git+https, otherwise I would get errors when pip was trying to split
the string at '+'. Not sure why it worked with the -e flag, though.
Implement a proof-of-concept page with a paypal 'Buy Now' button. (refs #1001).

I implemented a simple page with a 'Buy Now' button.
Upon clicking the button, the user is taken to the Paypal page, where he can
make the purchase. After the purchase is made, the user is redirected back to our
website, with PDT variables in the URL.

The django-paypal module takes care of retreiving and displaying transaction info.
We will want to customize the view, but I haven't yet figured out how to do that.
I hope django-paypal lets you do that in a relatively clean way.

I also implemented an IPN listener, that for now only prints a message to the log
when an IPN request indicating successful payment comes in. Paypal docs warn that
one should guard for duplicates, but it looks like django-paypal already does that.
We should however check that the receiver address, the amount, and item code are correct;
this is yet to be implemented.

Since I can't convince my router to make my computer reachable from the outside internet,
I wasn't yet able to test whether IPN works. I plan to deploy on test.cardstories.org and
check how well that works.
Fix paypal urls and override the PDT template (refs #1001).

I was using the CS webservice host/url rather than the django one by accident;
fixed now by using settings.BASE_URL instead of settings.CARDSTORIES_HOST.

Also figured out how to override the template the the django-paypal PDT handler
uses to display transaction information to the user (it was easy, thanks django-paypal).
Merge branch 'master' of git://gitorious.org/cardstories-mtyaka/cardstories
Implement grant_cards_to_player(player, cards) on the service (closes #1003).

This implements a HTTP endpoint on the service which, when called, grants player
a set of cards as passed in in with the arguments.

The endpoint should only be accessible from the local network (django), so that players
can't grant themselves cards simply by POSTing to an url.

Securing the endpoint is left as an excercise to the reader.

Or maybe we'll add a separate task to do that :).