Help page seeds should only overwrite posts that have not been edited through the user interface

[trichoplax]

Describe the bug
Before merging #988 we need to be sure that running UPDATE_POSTS=true rails db:seed from the terminal will only overwrite posts (help page content) that have not already been edited through the user interface.

At present it appears that this overwriting is only prevented when the edit includes text outside HTML tags. This means that an admin could edit a help page to add a sentence in a <p> tag (contained within <p> and </p>) and this would not be detected as something to avoid overwriting.

To Reproduce
Steps to reproduce the behavior: (in a local development environment)

1. Run UPDATE_POSTS=true rails db:seed and note how many posts are listed as having been updated:

   Post: Created 0, updated 16, skipped 4
   

2. Edit one of the help pages (that has never been edited before) to contain an additional example text that is outside all HTML tags
3. Run UPDATE_POSTS=true rails db:seed and note how many posts are listed as having been updated:

   Post: Created 0, updated 15, skipped 5
   

   • Notice that this is one fewer than the number updated previously (as intended)
   • Notice that the edited help page has retained its added example text (as intended)
4. Edit a different one of the help pages (that has never been edited before) to contain an additional <p>example text</p> (this time contained in a <p> tag)
5. Run UPDATE_POSTS=true rails db:seed and note how many posts are listed as having been updated:

   Post: Created 0, updated 15, skipped 5
   

   • Notice that this has not decreased since last time (which is incorrect behaviour)
   • Notice that the edited help page has lost its added <p>example text</p> (which is incorrect behaviour)

Expected behavior
When running UPDATE_POSTS=true rails db:seed only posts that have never been edited through the user interface should be updated. This should apply equally regardless of the nature of the edit (HTML/not).

[cellio]

I'm marking this high priority because it's not just us; other deployments could be affected too.

I don't know what component to set here (deployment? ruby?).

If we track change history for help topics then presumably the fix is to only apply the change if there have been no non-seed-script changes. If we don't currently track change history for help topics, we probably should (and that would enable some other requested changes). I think having the seeder inspect a diff to decide would be fragile.

[Oaphi]

@trichoplax this should be fixed by #1201 - I've checked just in case, but don't want to close until you confirm that it's resolved.