Default to hard rollback

[alecgibson]

In general, the invert() method is not very reliable as an API. Neither json0 and json1 guarantee that any given op is invertible. This can lead to surprising data states when using a "soft" rollback. We should probably default to hard rollback in all cases, and force consumers to opt-in if they want this behaviour (which means they should also hopefully know what they're doing).

Further discussion:

• Do not invert automatically in Doc.prototype._rollback #442
• Add preventInvertInRollback option #443

[alecgibson]

Discussed with @ericyhwang — sounds like a sensible thing to do.

Flag-wise, we can add one at the global level to help consumers ease transition, and also set per-doc for more granular control. We'd need to have "ternary" logic at the doc level: null means inherit from the global flag, or if we've actively set it to true or false, then we should use the doc flag.

[curran]

This seems like a good direction to me.

[hsource]

I did a more targeted and backwards-compatible fix in #520 - Fall back to doing a _hardRollback when op.type.invert fails. Let me know if you have any feedback on that! We're running that in a patched production build already.

This can be helpful even if you do change the defaults, as it makes those cases not totally ignore the rollback.