Add the `parent_clock` call on update to the Model for map_eqc

[russelldb]

When the map performs an update to a field,it replaces the embedded crdt's clock with it's own. It does this because context operations on fields in a map take the maps context.

This leads to a neat semantic change: when you remove a set or flag, and then re-add it by updating, the new entry gets the Maps clock, which means it has seen all the elements that were removed by removing the field. This leads to a defacto reset-remove semantic for sets and flags. Assuming time goes forward the same is true for lwwreg. Only counters have a strange semantic on field remove | re-add now.

Note: just adding the field does not lead to this behaviour, only and update causes the clock to be replaced. Otherwise an add to a field that is present would be short hand for "remove, then add" (which maybe it should be??)

[seancribbs]

Running 3 hours of examples, will report back later.

[seancribbs]

OK, passed 289159 tests

21.73849% {map_eqc,update,4}
21.67330% {map_eqc,add,4}
16.70666% {map_eqc,replicate,3}
12.45884% {map_eqc,remove,2}
10.95082% {map_eqc,ctx_remove,4}
10.30505% {map_eqc,make_ring,2}
6.16685% {map_eqc,set_n,1}
true

[seancribbs]

:+1: 424ef3b

[russelldb]

OK, passed 1000000 tests

21.70859% {map_eqc,update,4} 21.67901% {map_eqc,add,4} 16.70317% {map_eqc,replicate,3} 12.46062% {map_eqc,remove,2} 10.94831% {map_eqc,ctx_remove,4} 10.32088% {map_eqc,make_ring,2} 6.17942% {map_eqc,set_n,1} true

[seancribbs]

Hmm, I thought we had @borshop on this repo. Anyway, cheers!