Refactor updating note content to stop directly mutating note object

[dmsnell]

See #1614

As part of a broader effort to resolve data-flow issues in the app this PR is a
first step in removing direct mutation where transactional atomic updates
should be occurring.

It's not clear if the existing code is the source of existing defects in the software
and this is part of why the code is problematic; we have created inherent
concurrency flaws that open up extremely-difficult-to-reproduce bugs.

Resolving this may or may not resolve any existing bugs but it will definitely
help guard us from introducing new ones.

---

Previously we have been directly mutating the note object when updating
its content. This may have been an attempt to work around confusing
data-flow issues that thankfully don't exist anymore. We have also been
performing inline checks to make sure that we update the editor's
contents if we receive these updates.

This mutation can lead to concurrency defects which expose themselves as
inconsistent UI state. This breaks our Redux model which assumes that
all UI updates happen atomically.

In this patch we're building a new note object when we update a note
in order to maintain our consistency. In light of #1598 we're also
removing some work-around code that attempted to force consistency when
it didn't exist; that consistency now exists since we're tracking the
underlying Simperium data closely now vs. storing it in separate
places.

When updating checklist items we're forcing a sync so that those changes
will propagate immediately. We don't have a need to debounce those
clicks.

---

Testing

There should be no significant visual or behavioral changes with this PR. We
adjust updating the note in the editor when receiving remote changes and when
making local changes. We touch the code which toggles checkboxes.

In testing verify that with separate sessions the updates appear as expected.
Toggle checkboxes on and off, from the editing screen and from the Markdown
preview screen as well.
Smoke-test to verify no breakage.

Make some changes, wait a moment, make other changes, wait a few moments more,
and verify that your edits make it through. Repeat but with conflicting edits. This is
to test the debouncing.

Notes

Since the only "action" that onUpdateContent was doing was loadAndSelectNote
when the edits occurred on the opened note I have remove that entirely. As of #1598
those edits should be mirrored exactly in the editor and so we don't need to re-select
it in order to force an update.

[sirbrillig]

Code looks good. It took me a bit to grok the new flow in onPreviewClick but I think I understand it. I haven't had a chance to run any tests yet, but figured it might be helpful to at least know that I had no comments on the code.

[dmsnell]

Thanks @sirbrillig - that flow actually bothered me and maybe what's causing that distress is the realization that we're not updating local app state with the new note contents. The old one wasn't doing this either, at least not through the recommended means but rather through direct mutation which could be wiped out immediately.

I'll consider this and see if we can't make up for it. All these data flows are still pretty hairy so I suspect that in the process of cleaning them up we may remove some flows, add some flows, add some flows that we removed, etc…

[dmsnell]

After more consideration @sirbrillig I'd like to leave this as-is because I think adding the fix you hint at would require substantially more out of this PR than would be manageable. I think it's good work but right now we're mostly updating the code and not changing behavior and I think doing what know we would prefer involve changing behavior.

That is, given the state-of-the-state the app isn't setup to handle dispatch( updateNoteContents( ) ) and the editor is already linked in to the underlying Simperium store. I'm afraid that if we added what I think we should add, a call to loadAndSelectNote then we would risk introducing a cycle into the app whereas right now things are stable enough as is.

I know you didn't require these changes but I thought you had a good point and I wanted to explore the idea.

[belcherj]

Code looks good. Tested well. No obvious issues.