Show storage add-ons in usage limits

[LMNTL]

Checklist

1. If you've added code that should be tested, add tests
2. If you've changed APIs, update (or create!) the documentation
3. Ensure the tests pass
4. Make sure that your code lints and that you've followed our coding style
5. Write a title and, if necessary, a description of your work suitable for publishing in our release notes
6. Mention any related issues in this repository (as #ISSUE) and in other repositories (as kobotoolbox/other#ISSUE)
7. Open an issue in the docs if there are UI/UX changes

Description

Previously purchase storage add-ons are now used in usage limit calculations. Corrects some issues that were causing incorrect limits to be displayed.

Notes

We previously determined whether to show the FREE_TIER_THRESHOLDS based on the logged-in user's join date. But for multi-user organizations, that meant each user in the organization could potentially see a different set of limits for their organization. This PR changes that so custom tiers are only shown if the organization owner joined before FREE_TIER_CUTOFF_DATE. If the user isn't in an organization, it still defaults to checking the user's join date.

[bufke]

I'm not a big fan of unit tests for JS, but I feel that getLimitsForMetadata and others have gotten too complex and merits it. Doesn't need to be now and happy to discuss. Tightening up the types (or simplifying) would mitigate my concern. It feels like the business logic has just gotten a bit too complex from where it started. It's not longer obvious at a glance as to what it's doing.

[bufke]

We discussed that the Environment API be better off not being user specific but that might be out of scope.

[bufke]

Possibly out of scope. If there was ever a good case for type hints, this is it. Lacking type hints, a DRF serializer on the Environments endpoint would help ensure correctness. But the environments endpoint doesn't have one. IMO this should be considered in a refactor. You could ponder if the added complexity here merits adding a serializer. While not as powerful as real type hints, the serializer would provide a runtime guarantee that data is returned in the expected format. Currently it's a untyped dict that is returned, which cannot provide proof that the API consistently returns the expected format the Frontend needs to accept.

[notion-workspace]

Update usage calculations to include Storage add-ons