# EPM-MB and staking-pallet integration

## Integration flow
- Staking calls `elect(page)` and receives back a `Result<BoundedSupports>`, which contains a page of bounded supports from EPM-MB.
- Staking transforms the supports into paged exposures by calling `Self::collect_exposures(supports)`
- exposures: `BoundedVec<(AccountId, Exposure), MaxExposuresPerPage>`
- `Exposure<AccountId, Balance> {total, own, others: Vec<IndividualExposure>}`

The transformation from bounded supports to paged exposures may be problematic IF the supports of the same voter for a given target are spread across pages (since the `Exposure.others` vec would need a search, perhaps?).

The new collect exposures would work as the following:

 let bounded_supports = EPM::elect(page)
 
 for each support in bounded_supports
     get current metadata for the (validator, era)
     if it exists
           calculate how many voters are left to fill the last page
           extend/append the last page's `other` nominators until fill it up
          
    add (remaining) paginated individual exposures to the storage 
    update exposures metadata in storage

(see current implementation of [`fn set_of_update_exposure`](https://github.com/paritytech/polkadot-sdk/pull/2504/files#diff-e88e18be93824b5e9d452a4a409a7d7982d3ae53508c7737d27269c200d0da0eR1231))

**API contact assumptions**:
1. ✅ For performance/fesibility reasons, pallet-staking should not iterate over the already processed `Exposures.others` vecs of all the paged exposures in storage. A tuple (`target, voter`) support needs to be atomic and the support of a given voter to a given target *must NOT* be spread across pages.
2. The supports with most stake will be included at the top pages and returned first by EPM-MB (to ensure that the election can run on partial pages and it has the highest stake possible).

## Paged bounded supports sorted by stake

In order to maximize the