moved to using decimals now that summing lists is involved, and we need to retain accuracy

still need to decide how the multipliers are going to be indexed. 0-indexed is easy, but it seems what to talk about a radio being "0th ranked" in a hex.

the speedtest multiplier is allowed to be zero. It can completely negate a radios rewards.
speedtest 2

it seems a more accurate name for where we are currently, I think

For the way we talk about Ranking of radios, it doesn't make much sense for a radio to be ranked 0th for a hex.

Removing hexes that do not meet the rank requirements is easier to think about in its own step

the HIP says estimated coverage points, but no one thinks of them that way, because there is nothing about them that is an esimate, they are very concrete values.

Now that we have some integration tests, we can trust what code is being used

I want this crate to make the algorithm one of the most important things. Hiding it inside a structs impl block seems not a great of doing that, I think. I also don't think the rewardable radio impl block should be moved to the top to make the algorithm more front and center, in my mind it would only make RewardableRadio look more important.

trust scores and covered hexes are linked in many ways. I'm opting to precompute multiple values then have quick access to them, rather than waiting until they're needed and computing them for every hex. Or carrying around a spot for computed data that get's filled on the first use.

When the rest of the types are fleshed out, some benchmarks will be done to determine if this is a problem.

Clippy wants the method to take ownership to follow the `to_*()` convention.

The original implementation allowed the upper limit as inclusive, and it was called out in PR as not matching the HIP.

#737

Provides a named boolean to the status of meeting subscriber thresholds. Also provides a nice place to add new states in the case more HIPs are passed regarding subscribers thresholds.

This may be hardcoded to a type in the future, but until we know that type, it's easy to make it generic and only enforce the radio returns the same type the coverage map is expecting

I don't know if i like all the helpers in here. but I'm not sure where to put them yet.

we're constructing a temporary rewardable radio to implement rewardable radio. If we make one directly, the coverage map doesn't have to care about the entire radio, just the key type.

Thresholds have already moved away from being solely about subscribers. And this makes clearer the fact that a radio being considered "valid" can have many factors, not only subscribers.

The mobile-verifier needs to be able to report on only the boosted hexes. The calculator is not concerned with that, but it can provide the necessary hooks for the mobile-verifier to create the boosted hexes report.

that belongs in mobile-verifier

Thought I got this with a previous commit, apparently not.
Also add some spacing for readability

the  coverage map is going to be used before entering this crate, so we don't need to put a restriction around it.

The restriction will be that we only accept types provided from that crate.

requires pulling in helium-crypto as a dev dependency for testing

return a calculator error if a rewardable radio cannot be constructed.

Despire data given as input, only output data used for calculation.

Enforce the rules of speedtests, min of 2, max of 6, ordered newest to oldest.
BoostedHexes contain the boosted value they used.
Location Trust Scores contain the trust score based on boosted hexes.

Make the fields private so users have to go through the constructor to get a radio, and cannot change values of fields after the fact, as it will not trigger anything to be recalculated.

needs to know about radio type

use contstructors when we can, that's when calculations are done for multipliers

There is more than 1 case that can preclude a radio from eligibility,
let's communicate that in a better way that a boolean.

allows us to remove radio_type getter from RewardableRadio

add comments to assertions

inner line comments "//!" describe what is above.
outer line comments "///" describe what is below.

Thank you Matty.

We can not need to worry about constructor naming conventions by moving
more decision making into the constructors themselves.

`RewardableRadio::new` now only brings to the surface the fact that
location trust scores need to know about coverage, and covered hexes
need to know about location trust multiplier. But nothing more internally.

"No, if the radio covers a boosted hex, then the location trust score is
calculated using the more restrictive distance_to_asserted rule." - bbalser

You could make the argument to remove these fields, they were used in
the construction of a radio, and play a critical role in determining
points. I chose to keep them around because if anything happens where
you have a radio and want information about values within, these fields
will be crucial in helping you figure that out.

rather than consuming a radio you were forced to construct, and
returning much of the same information in a different shape. You get to
keep the radio you've made, and if you want to know about both, you can
hold on to both.

This tests cares about the relative value of the speedtest multiplier
being applied. As long as that relationship holds, this test is fine. It
doesn't want to worry about arbitrary points changing.

This allows us to be more specific about how much a hex contributes to
each type of radio without needing to know how individual hex values stack.

There's nothing that can be further enforced by having a newtype.
Making the field as `_millis` communicates the same ammount of
information as the newtype.

We don't need to enforce passing references for Copy types, let people
use them directly and the compiler can figure it out.

Rather than testing statements like "the multiplier should be an average
of the scores". This module benefits more from describing the different
scenarios, and showing boosted and unboosted versions in contrast with
each other, I think.

There's nothing that can be further enforced by having a newtype.
Making the field as `meters_from_` communicates the same ammount of
information as the newtype.

having bare coverage_point names laying around can be quickly confusing.

Speaking of a single rank at a time simplifies the test by not needing
to know how values stack on top of each other.

I kept indoor/outdoor as separate tests as to not overwhelm the reader
with a parameterized test that has too many variables

copy/paste error from rebasing on top of coverage-map updates, yay!
But now we know the tests break.

I agree with the concept, so I've added the lower bounds.
Personally, I still think these match statements are easier to read than
the equivalent `else if` expression. So they're staying as range
comparisons.

I like the idea of the API to this crate being 2 functions. In my head,
that makes it clearer that any functions hanging off of exposed structs
can be used for information gathering, but are ancillary to the main use
of this crate.

This puts the information about the radio closer to each other, the
grouping feels nicer, I think

this is stepping towards having a single struct

This means we don't need to unwrap anything, and the API is more
strictly dealing with data alone.

The location funtions are only public to the crate to prevent someone
from attempting to put together they're own coverage points calculator.

They must go through the calculate_coverage_points function.

Same as location, we want to deal more directly with data, while keeping
the only way to use the crate be through the top level
calculate_coverage_points function.

dealing more directly with data.
forcing use through the top level api.