Player coming in can confuse dealer to think everyone is all in when that's not the case

[ctm]

Find and fix the problem that can occur when a third player enters a two player game (it probably can happen with more players, too, but it's trivial to reproduce with two).

I noticed this as I was testing re-entries (#1241). If I'm playing with two players and the new player comes in and has to sit out a hand, the next hand plays as if there's one fewer player. I strongly suspect we're initializing the player count before bringing in the sitting out player.

I can reproduce this on master by creating a tournament that starts with two players, playing exactly one hand, then having a third join, playing the next hand (where the third player will have to sit out) and then, on the next hand have one player raise and the next player fold. At that point there will be two live players, but the board, turn and river will be dealt as though everyone is all in.

[ctm]

Part (perhaps all)of the problem is that players can come in between begin_hand_pre_shuffle and begin_hand_post_shuffle and the responsibilities for each of those two functions are not really specified due to how they came about. Specifically, I cut begin_hand in half to add the shuffle sound years ago, with no thought about late registration or re-entries. I believe the only reason I did this was to add the sound of cards shuffling, although that introduces the question of why anything would be done in pre, other than the call to pause(pause::Shuffled).

Looking at pre, I can see a number of state changes that logically should go in post, but I'm very nervous to move them since this code has been working for so long and I'm afraid that there might be tricky undocumented semantics that could bite me (Monsters Under the Bed!!). Realistically, I think I need to just suck it up and look at everything line by line and do as much to minimize pre as possible, which could include doing some state changes in both pre and post since pre is currently where we need to detect too few players and I believe we still need to call prepare_for_next_hand on all the players just to be able to tell if we need to pause, however, if players get moved in during the shuffle, they too need to be prepared, although it would be possible for the motion code to detect if they're being moved between pre and post and call prepare_for_next_hand then.

I believe that any state change that doesn't involve the players can remain in pre, so that significantly cuts down the number of lines that are serious candidates to either move to post or to call twice, but I still want to look at each one fairly carefully in case I'm overlooking something.

[ctm]

Before I do the above, I also saw that sit_out_players_between_button_and_small_blind sat out two of the three players in one of my tests, which may be due to the pre and post issue I describe in the above comment. Since it may be the same problem, looking at sit_out_players... first makes sense because if I do the other work first and then I can't reproduce sit_out, I won't know if I actually fixed it or if I just made an edge case even harder to hit.

[ctm]

Nope. I spent more time writing my previous comment than I did figuring out the problem. The problem is indeed separate in that when there are two players the button is the small blind and my code didn't take into consideration that we can transition from 2 players to 3 players since that was impossible before we had late-registrations or re-entries.

[ctm]

Fixed both of the problems mentioned above, with each fix being a separate commit. Deploying now.