Hide canonical posts from sitemaps

[diedexx]

Context

• Posts that have a canonical url set, shouldn't end up in the sitemaps.

Summary

This PR can be summarized in the following changelog entry:

• Fixes an unreleased bug where posts would still be in the sitemaps even though they have a canonical url set to another url.

Relevant technical choices:

• I still include an entry if the sitemap if the canonical url matches the post permalink exactly. If the post is /something and the canonical is /something/ it still is removed from the sitemap. This behaviour is now the same as in trunk.

Test instructions

Test instructions for the acceptance test before the PR gets merged

This PR can be acceptance tested by following these steps:

• Open the posts sitemaps
• Click a single entry in the sitemap and edit that post: under the Advanced section in the metabox, give it a canonical url. This can be any besides the url of the post.
• Save the post and visit the sitemap again. The edited post should no longer be visible in the sitemap
• Change the canonical url to the permalink of the post itself.
• Save the post and view the sitemap again. The post should be back in the sitemap.

Test instructions for QA when the code is in the RC

• QA should use the same steps as above.

QA can test this PR by following these steps:

Impact check

This PR affects the following parts of the plugin, which may require extra testing:

UI changes

• This PR changes the UI in the plugin. I have added the 'UI change' label to this PR.

Other environments

• This PR also affects Shopify. I have added a changelog entry starting with [shopify-seo] and I have added test instructions for Shopify.

Documentation

• I have written documentation for this change.

Quality assurance

• I have tested this code to the best of my abilities
• I have added unittests to verify the code works as intended
• If any part of the code is behind a feature flag, my test instructions also cover cases where the feature flag is switched off.

Fixes #

[diedexx]

Merging this now so we can test the feature branch on staging. A CR can come later and feedback can be processed in a new branch.