Add link counter

[tinykite]

What this does

• Adds a new component, LinkCount plus two new additional store properties, subscriptionStatus and userTypes.

Notes

• I initially found it hard to reason about the nested if/else statements in the original Django code, so I mapped out a decision tree related to the link count, and then created a tentative single, unambiguous subscriptionStatus state that could be derived from the conditional logic of the tree.
  • For example, a user may have metered, pay-as-you-go access to new Perma links. Or users may have unlimited links — on a paid or unpaid/free basis. (Or there may be an issue with their credit card on file)
  • If there are better terms for these categories, I am definitely all ears.
• If I understand correctly, there may also be more than one user account type associated with an account. For example, someone may be an individual user and staff. (Or an individual user and a sponsored user, perhaps?) I created userTypes to potentially easily reference these values, but right now we only needed to store whether or not someone is an individual.
• I switched a css class from an id to a class so that it didn't need to be unique, and could be applied to both the current link counter and the modernized one.

Screenshots

Displaying the remaining metere links a user has available.

Displaying the remaining metered links a user has available for the rest of the year, if they have an annually renewing Perma subscription.

Notifying a user they have paid for unlimited perma links.

Notifying a free Perma user they have been upgraded to unlimited free perma links.

Notifying any individual Perma user that they have an issue with their billing details.

While gathering these screenshots, I noticed that we don't always consistently use periods to end statements. Should we consistently do so? (Or remove the instances where we do use periods?)

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 70.35%. Comparing base (41b6638) to head (c1eaead). Report is 72 commits behind head on develop.

:exclamation: Current head c1eaead differs from pull request most recent head d109992. Consider uploading reports for the commit d109992 to get more accurate results

Additional details and impacted files

```diff @@ Coverage Diff @@ ## develop #3499 +/- ## =========================================== + Coverage 70.33% 70.35% +0.02% =========================================== Files 48 48 Lines 6613 6611 -2 =========================================== Hits 4651 4651 + Misses 1962 1960 -2 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[tinykite]

Love the question about some things ending in periods and some not. I guarantee that is by accident. What do you think looks best? Consistently using periods?

I think using periods is the most consistent. Where I've worked at the past, it was our style to always add periods to statements (regardless of if it was a complete statement) and feels the easiest to reason about. Updated this in revision 839094c

Additionally regarding the new variables — yes! I am always in favor of simplifying this if possible, I'll file this away in my brain as a possible future improvement.