Preserve table chat

[ctm]

Make it so when you join a table, you can see all the chat that has occurred.

When I implemented chat, I consciously chose to not play back chat from before a player joins a table, out of a (misplaced, in retrospect) desire for "appropriate" privacy. My thinking was that in real life, if someone says something at a table and you weren't there at the time, you didn't hear it.

However, this overlooks the fact that in real life, dealers (and other players) can be informative and choose when to repeat bits of information that newcomers to the table should know. With mb2, it's kind of the opposite in that chat is easy to overlook in general and it's also easy to overlook when a new player has come in (especially with table splitting, and re-entries).

Yesterday's evening tournament, for example, had a bug (#1412) that I noticed on the first hand of the game, so I pointed it out to everyone present, but due to late entry, one player didn't get the message. That was the straw that broke the camel's back.

In real life, if you say something at a table, someone who is not there may wind up hearing it anyway, either via a human repeating what has been said or perhaps by a recording device (e.g. phone). So, deliberately throwing away chat the way mb2 currently does doesn't even really approximate real life.

[ctm]

This isn't that hard, but it does mean that NickMapper can no longer handle Chat messages. They have to go to the Table so they can be retained. I think that's still a trivial change, but I don't think I'll get it done in time for this evening's game.

[ctm]

Deploying now. I don't think a deploy takes 13 minutes anymore…

[ctm]

Turns out, there was a reason NickMapper was handling Chat messages: so logged-in, but not playing players can chat. NickMapper knows the TableId, but that info isn't passed on to RunningEvent, because all the UserRequests contain PlayerId and that's sufficient to identify the relevant Table, because UserRequests are for players who are playing.

So, the solution is to create a RoutedChat Request variant and have it include the TableId and then convert a Chat message in NickMapper to a RoutedChat to send to RunningEvent and then have RunningEvent use the TableId for routing, but send a Chat message to the relevant Tournament. It's an annoying special case, but no more annoying than having Chat processed directly by NickMapper.

[ctm]

Fixed. Deploying now.