Introducing this change might lead us into NullPointerException since we don't assign encrypted field to every notification, even after landing this entire stack. This field is used as follows:

1. There is no encrypted field: notification was not supposed to be encrypted.
2. There is encrypted field and it is set to 0: notification was supposed to be encrypted but encryption failed on the keyserver side.
3. There is encrypted field and it is set to 1: notification was supposed to be encrypted and encryption was successfull.

We don't modify which keys are present and which are not, but we modify values that are stored under those keys. Therefore according to the docs: https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#keySet-- iterating directly over keySet output might not be safe. That is why I created the copy of keys present in the map first.

There are a couple of reasons here:

1. Not every field is encrypted, but I understand we could just store encrypted JSON blob under some key along with other keys that are not encrypted.
2. On iOS we encrypt field by field since some keys presence it probably required by APN.
3. No security concerns about field by field encryption were raised in discussions under relevant Linear issues: https://linear.app/comm/issue/ENG-2864/decide-which-parts-of-notifications-for-each-platforms-are-going-to-be.
4. We should ask @anunay whether encrypting entire JSON blob is more efficient in terms of size than encrypting each field separately. My intuition is that there is not single answer to this question but rather there is some treshold which changes the preferred approach.

In conclusion:

1. If there are security issues about field-byfield approach then we should implement field by field approach.
2. If there are not security issues about field-by-field approach we should decide based on which is less likely to overflow fcm size limit.

cc @ashoat

1. If Android notification was supposed to be encrypted and was successfully encrypted it will contain encryptedPayload field.
2. If Android notification was supposed to be encrypted but was not successfully encrypted it will contain encryptionFailed field.

As far as I know JSON cannot contain nulls or undefined so we cannot differentiate between 1 and 2 with empty encryptedPayload field.
Setting a flag encryptionSuccessful that would be either 1 or 0 and then additionally setting encryptedPayload would be a waste of space.

This exception should never occurr. JsonReader class is designed to cover the case of online stream of json tokens and this is why IOException appears in this method signature. However we are dealing with offline in-memory data.

At line 256 we repeatedly call nextString method since based on parent differential we expect that encrypted payload of Android notifications is a string-> string map. This method will throw IllegalStateException if we call nextString but the currently read field is not string. In our case it would mean the server side developer changed Android notification structure but they forgot to update native Android notifications code. We can consider it as native invariant.

JsonReader methods: beginObject, endObject, hasNext and nextString might throw either IOException or IllegalStateException which have already been handled. Therefore any other exception must come from NotificationsCryptoModule. that is why we print this error with "Failed to decrypt encrypted notification" message,

Ok, makes sense, but having a warning on native client might not be enough to let us know about the issue. We should add some comments in the code that generates notifs that all the Android clients assume that notif is flat.