I2I: Make RTC’s timeout mechanism more flexible

### Summary

Permutive is an Audience Platform for publishers and advertisers. We have a strong focus on privacy and first-party data: enabling publishers to use their data to power advertising and personalization in real-time, across every device, browser and environment, while respecting user privacy.

One of the essential capabilities we provide publishers is the ability to dynamically target their ads, based on a user's behaviour.

Our previous proposals for amp-script, amp-ad, and amp-analytics have allowed publishers to personalise the user experience on AMP as they would on regular websites.

This proposal builds upon our previous proposal for amp-ad, #33581, which was implemented in this PR #33872, and puts forward a use case for users of RTC config to have more granular control over timeout as well as RTC config having better support for amp-script URIs.

### Design Document

1. We will need to introduce a polling fn with a timeout to wait until the amp-script in question has exposed the function that RTC needs to call to get targeting data.
2. Changing the timeout behaviour might be as simple as respecting the value that has been passed in as opposed to enforcing a maximum of 1000ms

### Motivation

The Permutive SDK enables publishers to target ads in real-time without having to send data back to our servers for processing.

To facilitate the way our SDK works and is deployed for publishers, we worked with the AMP team to bring a new mode for amp-script called `sandboxed` mode, which was implemented here #33643.

This allows our SDK to run client-side on AMP, segmenting users in real-time without their personal data ever leaving their device.

One key feature of the changes we worked on with the AMP team, outlined in the issue mentioned above, was the ability for `amp-ad` components to fetch targeting information from a function exposed by an `amp-script` script. For our SDK, this meant that we can take advantage of our real-time segmenting technology to pass on up-to-date segment data to `amp-ad` that are all evaluated on the client.

However, since trialling this with a few of publishers we have run into performance issues.

As our SDK is served via our CDN, the combination of fetching this, as well as the time it takes to bootstrap a `sandboxed` `amp-script` component means that `amp-ad` RTC calls are often made before our SDK is ready to provide information to external services and components.

This is especially troublesome on low powered devices and low bandwidth connections, where our SDK is usually too late to pass on targeting information to `amp-ad`

Our proposed solution to this is two-fold:

1. As with HTTP requests to fetch targeting data, the timer for `amp-script` URIs should start once the call to the exported function is made.
1. This would inevitably involve having a polling function that keeps on checking until the `amp-script` component in question is ready and has exported the required function.
2. Once the function is ready, RTC will call that fn and then begin the timer until the timeout to wait for a response
2. A more customisable RTC timeout. Currently, RTC timeout has a maximum value of 1000ms. We appreciate that this is to keep amp-ads as performant as and is a reasonable maximum timeout for HTTP RTC calls.
1. We propose making this more customisable, either by increase the maximum limit, or leaving the maximum limit open to the publishers to decide
2. We propose allowing the publisher to make the trade-off between better targeting performance and a longer maximum delay to triggering the ad request in this case.

### Alternative Solutions

1. Changing the `localStorage.getItem` proxy in `amp-script` to become an async function that fetches data from actual LocalStorage. It will have to async because it’ll be crossing thread boundaries in JS (from worker to iframe to the main page and then back)
1. **How this helps**: Any `amp-script` can now get whatever is the latest data for a given key from localStorage.
1. We can keep our inline script as is.
2. Customer will not need to change anything in their deployment
2. **Caveats**:
1. No longer has the same signature as the browser’s `getItem` implementation
2. It might take a while for data to cross boundaries (worker + iframe + page)
2. `amp-ad` gets direct access to LocalStorage to get data directly
1. Takes away the middleman
2. Can always query the latest values from LS
3. Won’t need to play with waiting times
4. Will need a mechanism to format data object according to what `amp-ad` expects

### Launch Tracker

_No response_

### Notifications

/cc @ampproject/wg-performance
/cc @ampproject/wg-ads-reviewers

Start by tracing RTC config handling and the amp-ad calls to functions exposed by sandboxed amp-script, focusing on when the timeout begins and how the 1000ms maximum is enforced. Compare the two proposed approaches in the issue and confirm that the completed behavior supports delayed function readiness and publisher-controlled timeout trade-offs.

Written by the indexing model from the issue text.