Sync tokens could be shorter by using a different base than 10 for encoding the digits

[deepbluev7]

Description:

Currently synapse uses base10 to encode sync tokens. In theory those numbers would be shorter in base16 or base64. I.e. take a sync token like s10944013_177839773_20782_15820050_775403_353_366142_138560250_31. If we encode the digits using base64, it goes from 66 chars to 46 characters (s_pv4N_CpmenQ_US4_8WUS_C9Tr_AWE_BZY-_CEJC-g_Hw). This saves about 30% for the sync token. Most sync requests include a sync token in the request as well as the response, so we could save 40 bytes on the requests.

While this is not a lot, it shouldn't cost any extra CPU (since you are just encoding the number in base64 instead of base10) and otherwise not really make a difference. We could even use a higher base than 64 in theory, although choosing an encoding that doesn't introduce encoding overhead in URLs is probably wise.

In general this won't save much in total, since even an almost empty sync request is a few hundred bytes usually (since it includes the e2ee key counts as well as one event usually, but it might be more helpful once CBOR encoding for http requests or responses becomes a thing. I'm just documenting this so I can say "This Nico guy was so ahead of the times!".