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 #1618 will not alter performance

_{Comparing ok-nick/remove-fetch-remote-manifest-flag (61a1416) with main (629ab6e)}

Summary

✅ 16 untouched
⏩ 2 skipped¹

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).