fix: correcting protocol parsing logic that may lead to incorrect sanitization of an incoming message from LD servers (#288)

After examining related code to a customer support case and #278,
noticed this modification during iteration. Theoretical issue is that
modification during iteration, even if not resulting in
ConcurrentModificationExceptions, could result in unpredictable
iteration and could possibly skip sanitizing certain incoming flags.

Through bench testing and instrumentation testing, I was unable to
reproduce the issue, but I suspect it may be dependent on the specific
platform's implementation of the Map type that GSON will depend on. Will
deploy this fix and work with customers to confirm if the occurrences of
the issue is eliminated.

Author: tanderson-ld

launchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/EnvironmentData.java

@@ -78,13 +78,13 @@ public static EnvironmentData fromJson(String json) throws SerializationExceptio
         // Normalize the data set to ensure that the flag keys are present not only as map keys,
         // but also in each Flag object. That is normally the case in data sent by LD, even though
         // it's redundant, but if for any reason it isn't we can transparently fix it.
-        for (Map.Entry<String, Flag> e: dataMap.entrySet()) {
-            Flag f = e.getValue();
+        for (Map.Entry<String, Flag> entry: dataMap.entrySet()) {
+            Flag f = entry.getValue();
             if (f.getKey() == null) {
-                f = new Flag(e.getKey(), f.getValue(), f.getVersion(), f.getFlagVersion(),
+                f = new Flag(entry.getKey(), f.getValue(), f.getVersion(), f.getFlagVersion(),
                         f.getVariation(), f.isTrackEvents(), f.isTrackReason(), f.getDebugEventsUntilDate(),
                         f.getReason(), f.getPrerequisites());
-                dataMap.put(e.getKey(), f);
+                entry.setValue(f);
             }
         }
         return new EnvironmentData(dataMap);