Extract PostSettingsDataProvider protocol

[crazytonyli]

Description

As discussed in a previous PR, extracting a protocol to unify the updating Post Settings code on both data types: AbstractPost and AnyPostWithEditContext.

I have organized the diff into smaller commits. It'd be easier to review commit by commit.

Testing instructions

Mainly regression tests in the regular Posts and Pages.

[dangermattic]

	2 Warnings
⚠️	View files have been modified, but no screenshot or video is included in the pull request. Consider adding some for clarity.
⚠️	This PR is larger than 500 lines of changes. Please consider splitting it into smaller PRs for easier and faster reviews.

Generated by 🚫 Danger

[sonarqubecloud]

Quality Gate passed

Issues
5 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[wpmobilebot]

📲 You can test the changes from this Pull Request in Jetpack by scanning the QR code below to install the corresponding build.

	App Name	Jetpack
	Configuration	Release-Alpha
	Build Number	31407
	Version	PR #25363
	Bundle ID	com.jetpack.alpha
	Commit	dfacacd
	Installation URL	5n1thac0vo850

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[wpmobilebot]

📲 You can test the changes from this Pull Request in WordPress by scanning the QR code below to install the corresponding build.

	App Name	WordPress
	Configuration	Release-Alpha
	Build Number	31407
	Version	PR #25363
	Bundle ID	org.wordpress.alpha
	Commit	dfacacd
	Installation URL	1mr3rsgj9sfsg

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[wpmobilebot]

🤖 Build Failure Analysis

This build has failures. Claude has analyzed them - check the build annotations for details.

[kean]

Thanks for the work on this! I wanted to share some thoughts on how this approach compares to the original suggestion of branching at the ViewModel level.

The idea behind that approach was to:

• Leave the existing PostSettingsViewModel completely untouched, eliminating any risk of regressions
• Introduce a new CustomPostSettingsViewModel alongside it (even if that means duplicating ~50% of the code, which is acceptable given the plan is to eventually remove the original)
• Later, remove PostSettingsViewModel and switch over to CustomPostSettingsViewModel with minimal code changes

Branching at the PostSettingsDataProvider level does work, but it introduces a fairly large diff to PostSettingsViewModel, which is what we were hoping to avoid. I also have a slight concern that PostSettingsDataProvider may be taking on responsibilities that go beyond wrapping the post data - for example, properties like navigationTitle and methods like suggestedTags() and save(settings:) feel more like ViewModel-level concerns:

swift    var navigationTitle: String {
        isPost ? Strings.postSettingsTitle : Strings.pageSettingsTitle
    }
    func suggestedTags() async throws -> [String] {
        try await TagSuggestionsService().getSuggestedTags(for: post)
    }
    func save(settings: PostSettings) async throws {
        let coordinator = PostCoordinator.shared
        if coordinator.isSyncAllowed(for: post) && post.status == settings.status {
            let revision = post.createRevision()
            settings.apply(to: revision)
            coordinator.setNeedsSync(for: revision)
        } else {
            let changes = settings.makeUpdateParameters(from: post)
            try await coordinator.save(post, changes: changes)
        }
    }

I guess my main question is whether this direction still gets us the benefits we were after - specifically, keeping PostSettingsViewModel regression-free and making its eventual removal straightforward, since we'd still need to remove PostSettingsDataProvider at that point too. Happy to discuss further.

[crazytonyli]

@kean Sorry, I misunderstood the original discussion. I can explore that direction.