fix: Remove fetch_remote_manifest feature

[ok-nick]

Removes the fetch_remote_manifest feature and changes the verify.remote_manifest_fetch setting to default to false. This is related to avoiding network requests by default in the SDK. Note this is NOT a backwards compatible change although effectively has the same behavior as if the feature wasn't enabled.

• Closes Configure fetching remote manifests with a setting versus feature flag #1434

[codspeed-hq]

CodSpeed Performance Report

Merging this PR will not alter performance

_{Comparing ok-nick/remove-fetch-remote-manifest-flag (ef4fbb1) with main (a4fbcdb)}

Summary

✅ 16 untouched benchmarks
⏩ 2 skipped benchmarks¹

Footnotes

1. 2 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[tmathern]

How does this impact the cli tools?

[ok-nick]

@tmathern I preserved the same behavior for c2patool. This PR only changes the SDK.

[tmathern]

Why is it a verify.remote_manifest_fetch settings? Verify implies a validation for me? But this is more a "read", in the sense we allow to get remote data.

What will be the expectations for the downstream SDKs? They all get the "remote manifest fetch" turned off by default and need to set the appropriate setting if they want it back?

[ok-nick]

Why is it a verify.remote_manifest_fetch settings? Verify implies a validation for me? But this is more a "read", in the sense we allow to get remote data.

Yes I agree, we should consider changing this, but we probably want to preserve backwards compatibility as well.

What will be the expectations for the downstream SDKs? They all get the "remote manifest fetch" turned off by default and need to set the appropriate setting if they want it back?

Yes this will change that functionality. I suggest we wait to merge this until we can pass settings to readers/builders individually.

[tmathern]

Why is it a verify.remote_manifest_fetch settings? Verify implies a validation for me? But this is more a "read", in the sense we allow to get remote data.

Yes I agree, we should consider changing this, but we probably want to preserve backwards compatibility as well.

What will be the expectations for the downstream SDKs? They all get the "remote manifest fetch" turned off by default and need to set the appropriate setting if they want it back?

Yes this will change that functionality. I suggest we wait to merge this until we can pass settings to readers/builders individually.

Sidenote: We are already breaking backwards compatibility with that change (builds will break, but I agree it's different than also breaking settings files... but it seems everyone who wants that functionality to stay will need to update settings anyway).

[tmathern]

@ok-nick Maybe a suggestion because there is a lot of related work in-flight: Group your PRs into a feature branch (as you sit fit)? So they will be easier to integrate together (since it seems they'll be in the same release too), and maybe easier to maintain while in their rbanch(es). Wdyt?

#1630 and #1618 I could see released together. For the rest, developer's choice!

[gpeacock]

I think this is the right change,now that we have resolvers in the API. Presumably the default resolver doesn't use http?
Definitely a hidden breaking change so this needs to be clearly documented in the Readme as something that behaves differently and now must be enabled.
So please add something to the README. about this.