feat: Restricted HTTP resolvers

[ok-nick]

Introduces a new RestrictedResolver struct to restrict an inner Sync/AsyncHttpResolver with the specified allowed list. For the SDK, this is used specifically with the core.allowed_network_hosts setting to constrain HTTP requests to a known list of allowed hosts.

The default behavior of the SDK is to wrap a Sync/AsyncGenericResolver with a RestrictedResolver using the core.allowed_network_hosts setting. Eventually HTTP resolvers and settings will be passed in directly as structs.

The behavior for core.allowed_network_hosts is defined as follows:

/// List of host patterns that are allowed for outbound network requests.
///
/// Each pattern may include:
/// - A scheme (e.g. `https://` or `http://`)
/// - A hostname, which may have a single leading wildcard (e.g. `*.contentauthenticity.org`)
///
/// Matching is case-insensitive. A wildcard pattern such as `*.contentauthenticity.org` matches
/// `sub.contentauthenticity.org`, but does not match `contentauthenticity.org` or `fakecontentauthenticity.org`.
/// If a scheme is present in the pattern, only URIs using the same scheme are considered a match. If the scheme
/// is omitted, any scheme is allowed as long as the host matches.
///
/// The behavior is as follows:
/// - `None` (default) no filtering enabled.
/// - `Some(vec)` where `vec` is empty, all outbound traffic is blocked.
/// - `Some(vec)` with at least one pattern, filtering enabled for only those patterns.
///
/// These settings are consumed by [`RestrictedResolver`].
///
/// For information on when the SDK might perform an outbound network request, see "[When do outbound network requests occur?]"
///
/// [When do outbound network requests occur?]: crate::http#when-do-outbound-network-requests-occur
/// [`HostPattern`]: crate::http::restricted::HostPattern
/// [`RestrictedResolver`]: crate::http::restricted::RestrictedResolver

[codspeed-hq]

CodSpeed Performance Report

Merging #1630 will not alter performance

_{Comparing ok-nick/restricted-http (bf2b76d) with main (70c4a1b)}

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

[scouten-adobe]

Very nice work

[tmathern]

@scouten-adobe @ok-nick constrain HTTP requests to a known list of allowed hosts. How and who will manage that list?
Answer: User-provided list. So we should be good here, and no defaults are included either! 👍

[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!

[ok-nick]

@tmathern I would keep #1618 separate because it is on hold until we have an API to pass settings to the reader/builder, unlike this PR.