Firstly build the Android app without applying this differential. Send a couple of notifications and issue `select * from olm_sessions;` query in `mariadb comm` shell after each notification. This way you will see that each notification results in advancing olm session version by two. The reason is that we encrypt notifications with and without message infos, to see whether version with message infos fits into fcm limit after encryption. This is the issue since the client has to skip keys and keep them forever. This issue is resolved with this differential alongside with blob service upload feature introduction.
Now the REAL test plan for this differential:
1. Change `NEXT_CODE_VERSION` to `0` in `lib/shared/version-utils.js`. Replace production blob service address with local blob service address in `CommAndroidNotificationsBlobServiceClient.java` and `lib/facts/blob-service.js`. Build Android app (can be emulator).
2. Sent ordinary (small) notification. Issue `select * from olm_sessions;` query. Ensure that with each notification olm session version is advanced by ONE. This tests the bug fix.
3. Background the app. Send big notification (type 5000 * 'x' in python shell and copy the string). Ensure that the banner is displayed in Android client. Kill the keyserver and open the app. Keyserver is killed but the message is visible since we fetched it from blob service.
4. Kill blob service. Repeat step 3. Ensure banner is displayed but the message is not visible after opening the app. This tests that `fallback` behaviour works properly.