If some RPC responses and MTP updates are received together a fake
requestId in the negative range was used and that way updates were
processed before responses.
That could lead to an incorrect "out" message flag when sending
messages to supergroups, because a broadcast update about the new
message without "out" flag was handled before the request response.
Now a separate response map and updates list are used and responses
are handled always before the updates.
If we start logging in and we know, that some of the authorization
keys were read from the hard drive, not generated, we destroy all
the existing authorization keys and start generating new keys.
