fix: process full server response

[st3v3nmw]

After this change, we're not fully processing the server's response leading to some weird behavior... like the client & server getting stuck since the client is not providing the expected exchange-token or sequence. And we end up not processing any messages hours after registration:

This behavior can be seen with the latest snap revisions from the edge channel (probably all revisions after revision 244).

Cause

Server responses look like:

{'client-accepted-types-hash': b'N\x82(WO\x9a\x11}E\xda\x91\xbb\xcf\xc6\\.',
 'messages': [],
 'next-exchange-token': b'3274f7dd-3e6a-4cfd-ae66-a43ed5845e42',
 'next-expected-sequence': 53,
 'server-api': '3.3',
 'server-uuid': b'f1a65772-c771-11ea-927a-0017a48f36ae'}

yet, the ServerResponse class looks like this:

@dataclass
class ServerResponse:
    """The HTTP response from the server after a message exchange."""

    server_uuid: str
    messages: List[Dict[str, Any]]

which means that after this asdict, the response passed to MessageExchange._handle_result looks like this 👇 yet that function expects the original response as is.

{'server_uuid': b'f1a65772-c771-11ea-927a-0017a48f36ae', 'messages': []}

Fix

Process the full server response while retaining the original field types (i.e. keeping bytes instead of str as before) and kebab-case while processing the message.

The server provides next-exchange-token as bytes & the client has been storing it that way. We need to convert it to str before using it as a header value in landscape.client.exchange.exchange_messages. After this change, we dropped that conversion which creates a bad header in landscape.lib.fetch.fetch (line 102):

>>> [f"{key}: {value}" for (key, value) in {"X-Exchange-Token": "token"}.items()]
['X-Exchange-Token: token']
>>> [f"{key}: {value}" for (key, value) in {"X-Exchange-Token": b"token"}.items()]
["X-Exchange-Token: b'token'"]

When the server receives this bad exchange token, it forces the client to re-register creating a clone :(.

[Perfect5th]

I don't see any issues with the code. Good find!