Optimize network calls wrt. game-state handling in the game view

[merowin]

See this conversation:

If we want to nit pick on efficiency, there are also a few low-hanging network issues I think we could also leave as follow-up tasks:

• Two state requests are sent on page load.

• Taking a seat sends N "unsubscribe" messages, we should only need to send 1.

• Two state messages are sent from the server when game state changes (I believe this is because the client subscribes to both the observer state and seat-specific state.

Originally posted by @benjaminpjones in #267 (comment)

[merowin]

This is probably fixed with #297

[benjaminpjones]

Oh yeah! The second two are definitely resolved. Is the first?

Two state requests are sent on page load.

[merowin]

Oh right, the first is not resolved yet. The endpoint /games/:gameId/state/initial returns the variant and config, which are not included in endpoint /games/:gameId/state. I haven't checked this, but I believe this structure may have incidentally fixed #266 So I would like to keep it.

But maybe we can avoid that both api calls get triggered at the start.

[benjaminpjones]

That's a good point! And tbh two REST calls at page load is not such a big deal. Let's go ahead and close both of these, and can revisit later if API calls become an issue.