optable-targeting: Review follow-ups (stored-request leak, plan resolution, api-timeout) - #6

The fallback looked for imp.ext.bidder, which is not a format the core
knows. Old-style params sit directly under imp.ext and the core moves
them to imp.ext.prebid.bidder for every imp that has no bidders there,
so the sampler now applies the same rule per imp instead of falling back
only when no imp at all has imp.ext.prebid.bidder.

An account config with "enrichment-percentage": null or
"bidder-enrichment-percentages": null overrides the defaults of the
properties class, and the sampler then failed on unboxing.

… mixed stored imps

When the raw hook deferred the call to the processed hook it returned
no_action, so user.ext.optable reached every bidder unless the processed
hook was in the plan. The raw hook now always cleans and keeps
user.ext.optable in the module context for the deferred call.

The raw hook also defers whenever the request or any imp references a
stored request, since bidders from stored imps were otherwise never
sampled. Sampling now runs only once, at the stage that makes the call.

The README now lists the processed hook as required.

An exception in the raw or processed auction request hook failed the hook
without applying the cleaner, so user.ext.optable reached the bidders.
Both hooks now catch it, log it and still return the cleaner update.

The call and the bidders to enrich are set together, so the bidder
request hook never sees bidders without a call to await.

…pi-timeout

CompositeHookExecutionPlan ignored hooks.default-account-execution-plan,
only looked at /openrtb2/auction, took the timeout of the first group of
the bidder request stage and cached the per-account result forever.

It now only tells whether the bidder request hook is configured for the
request, combining the host plan with the account plan (or the default
account plan) for the request's endpoint, without caching. Whether the
raw hook has run comes from the module context.

The call awaited by the bidder request hook is bound by the new
api-timeout parameter, or by the time remaining for the auction.

The raw stage never runs for amp and video requests, so when the bidder
request hook is configured the processed hook now starts the call there
instead of passing through without one. When the raw hook has run and the
bidder request hook is absent, the processed hook awaits the early call
and enriches the request, as before.

…gacy setup

Without the raw and bidder request hooks the processed hook called the
API and enriched every request, whatever enrich-web, enrich-app and the
enrichment percentages said. It now skips disabled traffic sources and
only calls the API when sampling selects at least one bidder.

… fix/optable-targeting-review-followups

# Conflicts:
#	extra/modules/optable-targeting/README.md
#	extra/modules/optable-targeting/src/main/java/org/prebid/server/hooks/modules/optable/targeting/v1/core/BidderEnrichmentSampler.java

… fix/optable-targeting-review-followups

# Conflicts:
#	extra/modules/optable-targeting/src/main/java/org/prebid/server/hooks/modules/optable/targeting/v1/core/OptableTargetingFlowResolver.java

The raw auction request stage does not run for them, and they were not
enriched before, so the processed hook keeps passing them through when
the bidder request hook is configured instead of starting the call.

… fix/optable-targeting-review-followups

Kept this branch's flow resolver and execution plan: it already samples once, defers stored imps and reads the default account plan. Adapted OptableTargetingFlowResolverTest to the raw-stage API here, where the cleaner is applied whether or not the call is deferred.

…ion or bidder request

Walks a request carrying every user.ext.optable id through each hook setup (raw + processed + bidder, processed + bidder, processed only), request shape (inline site/app, stored imp, app from a stored request, disabled traffic source) and outcome (enriched, sampled out, no data, API error, hook exception). Each stage works on a copy, as the core's stored request merge and bidder request split do, so a cleaner applied later cannot hide a leak earlier.

…test

… fix/optable-targeting-review-followups

# Conflicts:
#	extra/modules/optable-targeting/src/main/java/org/prebid/server/hooks/modules/optable/targeting/v1/core/OptableTargetingFlowResolver.java
#	extra/modules/optable-targeting/src/test/java/org/prebid/server/hooks/modules/optable/targeting/v1/core/OptableTargetingFlowResolverTest.java