Remove Writable Gateway

[hacdias]

Checklist

• My issue is specific & actionable.
• I am not suggesting a protocol enhancement.
• I have searched on the issue tracker for my issue.

Description

We deprecated the writable gateway in 0.19.0 (#9622). I'm creating this issue to track its complete removal so we have less code to maintain and less sources of possible bugs. I vote on removing it in 0.20. It's a relative simple removal. Wdyt? @ipfs/kubo-maintainers

[BigLep]

@hacdias : I'm in favor.

[guseggert]

Do we know if there are any users of it?

[lidel]

The legacy Gateway.Writable is opt-in, so removing it won't be the end of the world, just awkward: it will break existing users without giving them a better replacement any time soon.

It was marked as deprecated to set expectations, so people don't build new things on it while we work on ipfs/specs#375. The plan was to improve onboarding data over HTTP POST, make it useful beyond flat files, support JSON/CBOR, blocks and CARs. Create IPIP spec for it, and replace the legacy writable gateway with better/more comprehensive API

Unfortunately, boxo and the Project Rhea happened, and our timelines/roadmaps changed again and again, but the rationale for ipfs/specs#375 is still valid, and I believe we should get back to it once we are done with Rhea.

[lidel]

That is to say: I don't know when we will be able to get back to HTTP POST work,
so maybe it is the lesser evil to remove the old API?
Make it so if someone has it enabled, refuse to start and print error pointing them at ipfs/specs#375.

This way users like ipfs/specs#375 (comment) will not be tempted to use legacy API, and be forced to use RPC at /api/v0/add for now.