It's bad to display a name based on a player order in the same place
as where you're letting people change that order and not have the
name change. So re-juggle the rematch process to allow the name to
be changed -- but don't change once the user has edited the name.
Now that rematching creates all the invitations and an expectation of
how the invitees will be ordered it'll confuse things if unexpected
players show up. So don't allow players to send additional
invitations.
When rematching, some users have a convention that e.g. lowest scoring
player in the "parent" game goes first. So allow that, providing the
choice on each rematch until a default has been chosen. Support
changing that default in a new prefs setting.
The place I chose to enforce the order was on the host as invitees are
registering and being assigned slots. But by then there's no longer
any connection to the game that was rematched, e.g. to use its
scores. So during the rematched game creation process I create and
store with the new game the necessary ordering information. For the
3-and-4 device case, it was also necessary to tweak the information
about other guests that the host sends guests (added during earlier
work on rematching.)
Two cases dealt with here. First, if my opponent deletes the game when
I have an un-ack'd message, I'll keep sending it forever. Fix is to
flip a bit in comms in response to a game_gone event so no more
sending will happen. (Better than emptying the queue, as it leaves
open the possibility of resurrecting the game with code changes
later.) Second, if there's a retained message from a dead game I'll
keep receiving it until it's replaced, and if the game's dead it never
will be. Fix is to add a new api endpoint noSuchGame() to the relay2
server and to call it on receiving a message for which I have no game
to deliver it to. The endpoint "unretains" the message so I won't get
it again unless it's resent.
