Use my set of permissions more than trying for individual ones, as
that's not enough on newer OS versions. Seems to work sometimes at
least, but maybe only after a new install.
To prevent deleted games' ghost invitations from remaining as
persisted on a topic and so being received over and over, have
recipient of invitation send an empty message on the same topic to
remove them. Any message sent once the game start would have replaced
the invitation, but sometimes if the sender is deleted at the right
time there's none.
MQTT must create the same header for each message, so having it set
the current timestamp is bad. I actually think it belongs in the comms
header, not in each transport.
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.
I'm looking for a test case to reproduce the Andorid situation where
invitations are never deleted from comms' queue and so prevent the
game from being considered over. Doesn't seem to happen in Linux, but
more tests are good.
Creating an address record without having heard from the remote is
new, and setting it to an old version was preventing using new msg
format. So set to new by default. Not sure how it'll get downgraded
facing an old client, but a 100-game upgrade test passes.....
Looks like invitations become unsendable before they're deleted
sometimes and so block sending real messages. This fixes device
accepting invitation but never hearing back from host.
This should complete sending to multiple topics (for backwards
compatibility) and supporting combined messages in the future (sending
them is hard; receiving not so much.)
