Instead of only returning the most severe one, return all applicable ones. This is because the reserved list has grown to a list of types that are not strictly comparable but orthogonal to each other. We can no longer depend on the fact that the most severe type incorporates all properties of those beneath it. Therefore returning all of them and treat them one by one in the calling site is the correct behavior.
Due to constraint imposed in eppcom.xsd, during domain checks the response can only contain a reservation reason of fewer than 32 characters, therefore we are returning the message for the type with highest severity, in case of multiple reservation types for a label.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=149776106
It was kind of messy having all of that logic living alongside the
entities themselves.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=148498024
This also cleans up the PremiumList API so that it only has one
method for checking premium prices, which is by TLD, rather than two.
I will be refactoring a lot of the static methods currently residing in
the PremiumList class into a separate utils class, but I don't want to
include too many changes in this one CL.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=148475345
This is better than the previous way of using the canonical name of the class,
because the previous way did not allow for refactoring, and also required the
PremiumPricingEngine to live in the model package lest there be circular
dependencies, which does not seem ideal.
Note that, for reasons of backwards compatibility with existing persisted data,
the name of the static premium pricing engine has been set to its canonical
class name, but the class can now be refactored going forward so long as this
string remains unchanged, and any new pricing engine implementations can use
whatever string key they want (it doesn't have to be a canonical class name).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=129215185
This properly reflects the fact that other, separate things will now
be responsible both for EAP and for per-TLD custom pricing.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=124558165
Second-level domain name isn't accurate because we support multi-part
TLDs, so standardize on the "fullyQualifiedDomainName" name that is
used throughout the code base.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=122693009
This refactors the existing premium list functionality into the new
class StaticPremiumListPricingEngine, which implements PricingEngine.
A backfill @OnLoad is provided to default existing Registry entities
into the static implementation. For now there is just this one
implementation. Dagger map multibinding is used to generate the total
set of allowed pricing engines, and allows other parties to plug in
their own implementations.
The pricing engine is a required field on the Registry object. If you
don't want a particular Registry to actually have a premium list, then
use the static pricing engine but don't actually set a premium list.
A subsequent CL will refactor the Key<PremiumList> field on the
Registry entity class to be handled solely by the
StaticPremiumListPricingEngine implementation. Going forward, all
configuration and implementation details that are specific to a given
pricing engine should be handled by that pricing engine, and not as
fields on the Registry object.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=121850176
