4.x perf optimizations

[yuzawa-san]

i have tried the 4.X branch out in a real production environment under real load. this allowed me to profile and kill off more hotspots. here are the main changes:

• optimize hot loops in AbstractLazilyEncodableSection. here we can skip allocating/calling iterators and just use simple for loops
• remove ManagedIntegerSet and ManagedFixedList. both of these wrapped the values returned by the field getValue() methods. this was in order for us to determine if the value returned was mutated. in that case the parent field would be marked as dirty. however we found we called a lot of the getValues on the same decoded field and it would return a new wrapper on each call. i was never fully satisfied with my original implementation here, so i reworked this into a different architecture. i introduced a Dirtyable interface which means that the values themselves can track mutations. i made the fields that return a collection return a Dirtyable implementation: IntegerSet, FixedIntegerList, FixedList.
• this allowed me to clean up the class hierarchy for IntegerSet. also this is a concrete class which means it have virtual dispatch instead of the more expensive interface dispatch.
• i also converted the method signatures to return FixedIntegerList instead of List<Integer>. that FixedIntegerList is much more optimized: store in a byte array, add methods for unboxed access.
• added tests

[Kevin-P-Kerr]

My only concern is that FixedIntegerList can only represent (I believe) 8 bit values. That works for this use case?

[yuzawa-san]

@Kevin-P-Kerr yes, the gpp state specs only represent values 0,1,2 as the values (e.g. SensitiveDataProcessing , KnownChildSensitiveDataConsents). theoretically it could have been packed even smaller, but i found byte the smallest primitive which has built-in casts to/from int.

[Kevin-P-Kerr]

this should be fine as the most typical values are 0,1,2 I believe