feat: feed legacy payload param

[nugaon]

This PR adds support for legacy feed payload resolution via a new query parameter swarm-feed-legacy-resolve. It allows clients to specify whether feed payloads should be handled using the legacy format or the newer format.

This change allows for better compatibility with different feed payload formats while making legacy resolution behavior explicit rather than implicit. It still defaults on wrapping root chunk of data.

Resolves #5155 #5156 #5157

Checklist

• I have read the coding guide.
• My change requires a documentation update, and I have done it.
• I have added tests to cover my changes.
• I have filled out the description and linked the related issues.

Description

Open API Spec Version Changes (if applicable)

Motivation and Context (Optional)

Related Issue (Optional)

Screenshots (if appropriate):

[acha-bill]

lgtm

[acha-bill]

Remove unused

[janos]

As this is a user facing feature, what would happen when the current feed structure becomes legacy. Since the structure can be changed and it is something that users interfere with over the api, I would suggest to have versioning on the feed, at least for api options (header in this case).

[nugaon]

the current feed usage wraps the root chunk of the referred content so there is no specific structure in the feed payload.

there is no proposal now to change the arbitrary legacy feed structure but if that's the case in the future, API could be versioned with that change as you mentioned - except the header part since it has problematic use-case #5157. maybe instead of a boolean, a version number can be used. but at the moment, I don't see why it would be necessary since there is only one version of structure of legacy feeds and most probably there won't be new one.

[janos]

maybe instead of a boolean, a version number can be used. but at the moment, I don't see why it would be necessary since there is only one version of structure of legacy feeds and most probably there won't be new one.

Exactly, instead of boolean, a version would make changes in the future much easier. With the boolean, a transition to some new header would be needed. In general, we do not know how things will change in the future, but we can prepare to handle changes. Since the change already happened creating legacy feeds, it is possible to have another change in the future.

[nugaon]

IMHO starting to version a legacy feature is futile and makes the code and the documentation more complex.
The whole point is to transition out of payload structures in feeds.

[janos]

IMHO starting to version a legacy feature is futile and makes the code and the documentation more complex. The whole point is to transition out of payload structures in feeds.

OK, as you wish, my opinion is different as described. We will handle the backward incompatible changes later, if they appear for this cli flag.

[gacevicljubisa]

If we use something like ?swarm-feed-format=legacy instead, it would be much easier to add other formats in the future if we need to. It's a small change now that could save us from a headache later on.

Other than that, the rest of the changes in the PR look great to me

[nugaon]

@gacevicljubisa the problem is the same from my perspective. also, just imagine you need to remember of the query name AND the "legacy" as well. if I needed to choose from any one them I would go with the simple versioning since that is simpler from this aspect.

[gacevicljubisa]

@gacevicljubisa the problem is the same from my perspective. also, just imagine you need to remember of the query name AND the "legacy" as well. if I needed to choose from any one them I would go with the simple versioning since that is simpler from this aspect.

I agree it adds a little more complexity, but either way, it's another custom parameter that users will have to look up in the documentation.

Since they'll be checking the docs regardless, I think the small extra step of typing =legacy (or something similar that will allow versioning) is a good trade-off. It makes the API more flexible for the future.

But if you insist, we can go with the current approach.