Because only the host/inviter knows the addresses of all the devices
in a game it's hard for guests to rematch (unless it's a 2-device
game, as they know the host's address.) So now, as part of telling
guests the game is ready to play, include the addresses of other
guests. It's usually only 9 bytes per device, and only happens when
more than two devices are in a game.
This is probably a temporary fix for Linux not being aggressive enough
about calling comms_resendAll() when opening a game. For now, though,
test scripts fail without it.
Rematch against self didn't work, and is useful for testing. So in
dutil method hasGame(), check if games with the same gameID are also
for the same channel. And when creating a new game for rematch, make
sure it's channel is 0.
Add dutil proc haveGame() and use it to detect duplicate
invitations. I'm passing, but ignoring on android, the channel, which
means that for now you can't invite yourself and on-device testing
requires having CrossWords and CrossDbg or a second user.
There was some confusion around host and self addresses, where they're
created, default values, removing conTypes from defaults that are not
in received host addr, etc. I left in some asserts to help understand
if code that seems wrong but hard to fix is still getting called.
Remove legacy relay-inspired logic around comms addressing. Now when a
device creates a game it's required to provide its "self address," and
if it's a client, the address of the host (which it presumably got
through the invitation in response to which the game is being
created.) Then as registration messages come in from clients, the host
gathers their addresses as always.
It's in the context of a game, and we might want info about the game
when notifying the user. For wasm, though, I just download after failure
to open. User has to try again to open the game. Good enough for now
since missing a wordlist shouldn't happen if you're not me changing
where they're stored.
It's awkward for platform code to create a dictionary prior to opening a
game whose data contains the information about what dict to open. So add
a dutil method to fetch a dict, and call it from inside game opening
code. Makes linux code better at least.
Not at all tested, but now the game's timestamp is kept and passed in to
where it can be used to determine, e.g., which of two Bluetooth device
names to keep for a given opponent.
