Try/remote post hash

[Deco354]

Part of Conflict Resolution Dialog Issue
DO NOT MERGE
Blocked awaiting WordPressKit PR enabling RemotePost hashing.

Description

At present we check whether a remote post has been updated by checking its dateModified property. This isn't a fool proof method of checking this so the hashing logic within AbstractPost has been extracted so it can be used by RemotePost within WordPressKit.

This PR

• Persistently saves a lastRemoteUpdateHash
• Hashes incoming remote updates and compares them with the lastRemoteUpdateHash
• Sets a version conflict if the new remote post has a different hash to the lastRemoteUpdateHash
• Updates AbstractPost to use the new SHAHasher class within WordPressKit
• Fixes a bug where version conflicts can sometimes have yellow labels instead of red ones.

Basic Test cases

1. Local Autosave Draft vs Remote Update

Reproduction Steps

• Create a post using the app and save as a draft
• Open the post, type some content and then close the app (without exiting the editor)
• Go to the web, change the post content and publish it

Desired outcomes:

• The post does not appear in the drafts tab
• The post appears within the published tab
• The post has a Version Conflict label

2. Local Autosave Publication vs Remote Update

Reproduction Steps

• Create a post on the web and publish
• Open the post in the app, type some content and then close the app (without exiting the editor)
• Go to the web, change the post content and publish the changes.

Desired Outcome

• The post appears in the published tab
• The post has a Version Conflict label

3. Remote autosave vs Local Autosave Draft

Reproduction Steps

• Create a post on the web and publish it
• Open the post in the app, type some content and then close the app (without exiting the editor)
• Open the post on the web, type some content, then click preview. Leave the preview but keep the post edit screen open
• Reopen the app and refresh post list

Desired Outcome

• The post does not have a version conflict label
• The post has a local changes label

PR submission checklist:

• I have considered adding unit tests where possible.
• I have considered adding accessibility improvements for my changes.
• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

[diegoreymendez]

Hey @Deco354. Right now this PR doesn't let me test the changes without first merging the changes in WordPressKit from your other PR.

Can you adjust the podfile so this PR can be tested using the modifications of WordPressKit before merging them?

Thanks!

[diegoreymendez]

@Deco354 - I just tried running the first test case, but I'm getting a crash. From what I could see it's related to one of the changes in this PR.

Can you check it out?

[Deco354]

Hey Diego, is it this one? Apologies I should have gave you a heads up on this.

This fails on develop for me as well.

The xcode tool tip corrections fix this although I refrained from committing it as I assumed by the time I merge this in to develop it will have been fixed.

Would you prefer if I commit this?

[diegoreymendez]

@Deco354 - No, I'm seeing a crash as soon as I try saving a post as draft. Have you tried re-running the first test scenario?

It seems to be related to the changes in the latest commit here: dcd2f30

[Deco354]

Ah thank you nice catch.
It should run now and I've added some tests for Post's
additionalContentHashes.