Remove PostServiceRemoteExtended and implementations

[mokagio]

They will be moved into WordPress and Jetpack.

The reason for this is that they are only used in WordPress and Jetpack and that they are Swift extensions of Objective-C types which we are trying to isolate.

It's simpler to move these leaf types into the only consumer that uses them than trying to re-architect them.

Description

Fixes #

ℹ Please replace the above with a link to the issue this pull request addresses, as well as a summary of the implementation details.

Testing Details

ℹ Please replace this with a clear and concise description of the steps required to validate this pull request.

---

• Please check here if your pull request includes additional test coverage.
• I have considered if this change warrants release notes and have added them to the appropriate section in the CHANGELOG.md if necessary.

[mokagio]

When the type became public, a public init became necessary because the compiler does not synthesize one outside of the package.

As for encode(to:), it needs to be public because Encodable is declared as part of the public type interface.

🤔 In hindsight, I suppose the Encodable part could be moved into an internal extension, but I think it's okay to leave it as is. Let me know if you can think of a strong reason to hide it.

[mokagio]

I didn't look up when, but relatively recently, I think, Swift acquired default values for associated parameters. So we can remove this builder method in favor of defining the underlying error as a default for the case.

[mokagio]

Became redundant once invalidTokenHandler became a property in the interface.

[kean]

@mokagio This code is a work in progress, and the respective PRs that integrate it in WordPress-iOS haven't been merged yet. Please hold off on making changes to this code until 24.8.

Initially, the idea and the naming of PostServiceRemoteExtended came from the need to add just two new methods to the service, but it turned out most of the existing method needed to be replaced.

[mokagio]

Hi @kean 🤔

There I was thinking hacking around WordPressKit was safe because it was relatively quiet these days 😅

What's your timeline for that work?

My priority right now is to get WordPressKit split into packages so that the majority of it can then go into WordPress and we can avoid back and forth like this.

Maybe I can help get your project over the line?

Initially, the idea and the naming of PostServiceRemoteExtended came from the need to add just two new methods to the service, but it turned out most of the existing method needed to be replaced.

Interesting. Did you consider making all the addition in WordPress itself? Or perhaps there's internal utils that need to be accessed in WordPressKit to get what you need done?

"Replaced" is an interesting choice of word. Do you mean that the now there are methods that are no longer in use? Or is it a matter of the new feature you and team are working on needs a lot of new methods that will live in parallel to the existing ones?

Thanks for the info.

[kean]

Did you consider making all the addition in WordPress itself? Or perhaps there's internal utils that need to be accessed in WordPressKit to get what you need done?
Do you mean that the now there are methods that are no longer in use? Or is it a matter of the new feature you and team are working on needs a lot of new methods that will live in parallel to the existing ones?

We've added new methods for creating and updating posts. I'm not sure it's possible to implement them outside of the framework, but I haven't tried or considered it. The old methods will no longer be used by the app once 24.8 rolls out.