fix(esp-sync): normalize contact data on direct upsert calls

[dkoo]

All Submissions:

• Have you followed the Newspack Contributing guideline?
• Does your code follow the WordPress' coding standards and VIP Go coding standards?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes proposed in this Pull Request:

#3362 removed normalize_contact_data as a filter on the newspack_newsletters_contact_data hook. However, this results in upsert calls that happen outside of this plugin's Sync classes to sync un-normalized metadata.

This PR restores the filter, but this will result in the data from upsert calls from the Sync classes being normalized twice. I'm open to feedback on how this can be improved, but for now this fixes the issue.

How to test the changes in this Pull Request:

1. On trunk in both this plugin and Newsletters, sign up for newsletter lists as a new reader via the Newsletter Subscription Form block.
2. Observe in the Logger output and in the connected ESP contact that the metadata synced upon registration contains raw, un-normalized metadata keys (e.g. connected_account instead of NP_Account or current_page_url instead of NP_Registration Page).
3. Check out this branch, repeat with a different email address and confirm that the synced metadata contains only normalized, prefixed keys.

Other information:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes, as applicable?
• Have you successfully ran tests with your changes locally?

[miguelpeixe]

Thank you for catching that!

I'll approve because this fixes the regression, but I think we could avoid the double normalization by having a separate filter for the ::subscribe(), which are the instances in which the Newsletters plugin updates a contact with metadata.

All other cases that use ::upsert() are list updates, which do not have metadata.

[leogermani]

Here's an alternative Automattic/newspack-newsletters#1648

[dkoo]

Closing in favor of #1648