Change AppLovin adapter to post-bid with bidfloor

[justadreamer]

Is your feature request related to a problem? Please describe.
AppLovin adapters currently do not work as intended.
AppLovin allows 2 scenarios: SDK bidding, traditional SDK mediation. For the former you need to be AppLovin's partner - and then they will make a server-side auction request on behalf of your SDK and if it wins - your SDK gets to render. That's not the case of Prebid SDK unfortunately as Prebid.org unlikely will every be AppLovin's partner.
The second path is traditional mediation - that is what currently used by Prebid's AppLovin adapter. You add a placement for your SDK and specify an adapter and a CPM floor value - and if your CPM turns out to be higher than other ad sources - you will be called and given a chance to request an ad.
The thing is that Prebid's AppLovin adapter does not request a bid inside the adapter which would be considered post-bid. Prebid's AppLovin adapter expects that app developer calls Prebid prior to the call to AppLovin, caches the bid and then if Prebid's AppLovin adapter is called by mediation - it will render the cached ad.

The problem with this is that unlike GAM AppLovin does not support keyword targeting the placements (that's AppLovin's notion similar to GAM's line items) that are set up per ad unit - thus there is no way to communicate bid price and compete with other ad sources in the primary waterfall. And because Prebid's AppLovin adapter is not post-bid - it ignores any custom parameters that AppLovin passes to the adapter. Otherwise it could have accepted bidfloor from AppLovin and called Prebid Server with this bidfloor as a parameter - that would have at least been a one-directional connection from AppLovin's placement to Prebid Server call - as the other direction (passing targeting keywords is not working).

Documentation:

• iOS AppLovin adapter: https://github.com/prebid/prebid-mobile-ios/blob/master/EventHandlers/PrebidMobileMAXAdapters/Sources/PrebidMAXMediationAdapter%2BMAAdViewAdapter.swift (note how it uses already loaded creative)
• AppLovin with custom SDK Networks https://developers.applovin.com/en/max/mediated-network-guides/integrating-custom-sdk-networks/
• Building a custom SDK network adapter for AppLovin: https://developers.applovin.com/en/max/demand-partners/building-a-custom-adapter
• How to setup AppLovin placements (what's in GAM called line items): https://docs.prebid.org/adops/mobile-rendering-max-line-item-setup.html

The last document essentially has a useless instruction to setup a bunch of placements with hb_pb keyword, but it does not affect anything.

Describe the solution you'd like
The AppLovin adapter needs to be reworked to enable post-bid scenario with bidfloor passed from the AL server. It allows sending arbitrary JSON per placement. The AppLovin placements should be setup with a low-granularity - say 3-5 placements with different bidfloor tiers. That bidfloor should be accepted by the AppLovin adapter and passed in the request to the Prebid Server. The loaded ad should be rendered as normal. That way Prebid SDK will act as a normal mediated SDK and compete using price floors of lower granularity. The Prebid AppLovin guide documentation has to be updated accordingly.

Describe alternatives you've considered
The current state of things is an alternative, alas non-working. Also partnering with AppLovin may be an alternative to enable bidding, however it's also not feasible because AppLovin expects a partner to provide an endpoint per region while there is no single endpoint for Prebid Server - there multiple hosting companies each having their own endpoints, so for Prebid.org it would mean having to setup a "proxy" server to umbrella all partners, which seems infeasible.

Additional context
Here are some screenshots from my test AL account:

[YuriyVelichkoPI]

Just for the note - for now, AppLovin integration resolves the targeting on the client side via the same Custom Parameters.

1. SDK makes the bid requests and caches the bid
2. Applovin makes an Ad Request and receives the Placements ordered by CPM
3. Each placement initiates the Prebid Adapter adapter
4. If Prebid SDK has a cached bid with the price corresponding to the current Placement (Line Item) it will be rendered
   • Otherwise, the Adapter will send a failover signal, and AppLovin SDK will process the following placement.

So, the SDK mimics the targeting.

https://docs.prebid.org/adops/mobile-rendering-max-line-item-setup.html

Anyway, the post-bid scenario described above makes sense too.