HIP 109 boost by device type

[michaeldjeffrey]

helium/proto#401
helium/helium-program-library#634

---

BoostedHexInfo.device_type added

Because legacy boosts exists (NULL in the database mapping to BoostedHexDeviceType::All), a single hex can now be considered boosted more than a single time. BoostedHexes carries n number of boosts per cell.

When asking for the current multiplier of a hex, the device type in question must be provided. All boosts that apply are combined.

parse_boosted_hex_info_from_database test

Because this project does not control the metadata db, I wanted to make sure BoostedHexDeviceType would correctly serialize as a part of BoostedHexInfo.

Looking at the helium-program-library implementation it wasn't clear how DeviceTypeV0 would make it's way into the database. There is a similar field DeviceType in mobile_hotspot_infos that has also uses a rust enum that is present as a jsonb column.

If that assumption turns out to be false, updating the test should lead us to the glory of correctly serializing device_type.

BoostedHexes and "expired boosts"

@bbalser and I talked about BoostedHexes only ever containing non-expired boosts.

Ideally, that would occur at the level of mobile-config when boosted hexes are being streamed out of the db. However, boosted hexes do not have a end_ts field that is easily queryable, and I'm not comfortable at this point in time putting that much math into a sql query.

I tried at each next level. In the end, I decided to give up on that goal for this PR. Tests using BoostedHexes directly would not have a way to enforce the contract of only holding actively boosted hexes, and now didn't feel like the correct time to dive into those tests to find a way they could.

[michaeldjeffrey]

let (_, rewards) = tokio::join!(
    // run rewards for poc and dc
    rewarder::reward_poc_and_dc(
        &pool,
        &hex_boosting_client,
        &mobile_rewards_client,
        &speedtest_avg_client,
        &epoch,
        dec!(0.0001)
    ),
    receive_expected_rewards(&mut mobile_rewards)
);

When I tried to run rewarder::reward_poc_and_dc by itself, then receive the rewards, the test would never finish. I do not understand why.

[andymck]

let (_, rewards) = tokio::join!(
    // run rewards for poc and dc
    rewarder::reward_poc_and_dc(
        &pool,
        &hex_boosting_client,
        &mobile_rewards_client,
        &speedtest_avg_client,
        &epoch,
        dec!(0.0001)
    ),
    receive_expected_rewards(&mut mobile_rewards)
);

When I tried to run rewarder::reward_poc_and_dc by itself, then receive the rewards, the test would never finish. I do not understand why.

This will be because the filesink writer awaits a oneshot response to indicate the file/s have been written to disk. If you do not call receive_expected_rewards then this oneshot never gets returned and thus the rewarder's writer will wait indefinitely. See link below for an example of the oneshot response being sent from the tests receive handler: https://github.com/helium/oracles/blob/main/mobile_verifier/tests/common/mod.rs#L35

[andymck]

Other than clippy not being happy, this all looks good to me.