This workspace is all about dealing with Service Provider Promotion Fund
allocation.

HIP-114
https://github.com/helium/HIP/blob/main/0114-incentive-escrow-fund-for-subscriber-referrals.md

Service Provider Promotions are stored in CarrierV0 on Solana.
To keep the mobile-verifier from talking to a chain, this service will
periodically check Solana and compare Service Providers allocations to
what is stored in S3.

If the values have changed, a new file will be output to a bucket for
the mobile-verifier rewarder to read from.

NOTE: Allocation Values are stored in Bps (Basis Points)
https://www.investopedia.com/terms/b/basispoint.asp

** Commands

*** ./promotion_fund write-solana

Fetch Allocation values from Solana and write them to S3.
This command _always_ writes an S3 file.

*** ./promotion_fund print-s3

Using the lookback time in the provided settings file, show the
Allocation values this service would start up with.

*** ./promotion_fund server

Start a server that reads from S3, then checks with Solana periodically
for updated Allocatino values. Writing new files when needed.

- ingest promotion rewards, nothing will be done with them until the
  processor is added into mobile-verifier.
- dump reward files
- add sp_allocations dummy field to rewarder output
- reward indexer mobile promotion type added

Otherwise inserting a new reward would match on the address and
continually change the reward_type column for no reason.

Default trait impls cannot be added to functions, but they can be added
to structs. This struct keeps us from needing to do the gross blank
generic filling in when we want a continuous file source with a decode
other than MsgDecodeFileInfoPollerParser.

Rather than always dealing with conrete numbers, now that Service
Providers can allocate a percentage of their rewards to promotions for
subscribers or gateways, it becomes easier to speak of everything in
percentages.

This is a quick overview of what a more detailed overview you will find
in the PR.

For every Service Provider (SP) we figure out how much of the total
rewards allocation they are being awarded for data transfer. We get the
percent they have allocated for promotions (essentially from solana, but
really s3), and we determine which percentage of the _total rewards
allocation_ that is.

If a SP is getting 50% of the total rewards, and they allocate 20% of
those rewards to promotions, then the SP will receive 40% of the total,
and promotions from them will represent 10% of the total.

We do that for all SPs. The unallocated percentage is then distributed
to the promotions of each SP. If there is more than enough unallocated
left over, each SP get's a matched percentage of the whole to what they
set aside. When there is not enough, they get a percentage equal to
their initial rewards percentage.

This is to keep a service provider from getting the bulk of extra
rewards by settings aside a large amount for promotions, and receiving
little in rewards for data transfer, but getting more for matching.

A SP may never receive more in matched rewards than they have allocated
themselves.

This makes invocations of rewarding look very consistent

because we're dealing with percentages, and not doing bankers rounding
or nearest even, the likelihood that a calculation comes out extremely
close to a hole number then gets rounded down is increased. Especially
when dealing with percentages to the 7th decimal point and a base number
in the trillions.

I'm hoping there's an easy way to do this someone can point me to

it get a bit verbose with all the service_provider flying around, but I
think it will be rather helpful when you only have the type and it
hasn't been aliased.

#856

truncating to 5 decimal places for a % can result in the summed
allocation exceeding 100%.

Thanks proptest

It has been noted that in tests a single bone is okay, as long as we're
not going over the allocated bones

let's not have the worst of both worlds where we comment out unused
code.
Remove the printlns, they're not hard to add back in if you need them.

For accounting reasons, Service Providers can have multiple payer keys
listed. We need to ensuure all their dc transfer are accumulated into
their service provider entry when we are generating rewards.

- Add settings `promotion_ingest`