API Optimizations

[functionzz]

Description

Applies the API optimizations found in #3823 to every API view.

• Conditionally prefetches fields based on the fields query parameter
• Includes a N+1 query problem fix for TermSearchListView
• Applies DynamicFieldsModelSerializer to ProjectLocaleIndividualView
• Adjusts TermListView tests

Fixes #3824.

Additional Notes

• ~Probably needs more tests for the TermListView~
• ~Needs more thorough testing for individual fields to ensure no N+1 query problems are introduced into the code~

[functionzz]

I noticed that the LocaleListView endpoint is slightly off in the inclusion of locales like bn-BD and bn-IN. Until we confirm that these are fully fixed (soon), let's not push this,

[functionzz]

I noticed that the LocaleListView endpoint is slightly off in the inclusion of locales like bn-BD and bn-IN. Until we confirm that these are fully fixed (soon), let's not push this,

To test this, you can first go to pontoon.mozilla.org/api/v2/locales and pontoon.mozilla.org/api/v2/locales/?fields=code, observe the inclusion of bn-BD and bn-IN.

To follow up on this comment, it seems the issue stems from the LocaleListView having the Locale queryset use .available() instead of .visible(), which conflicts with the behaviour of the .stats_data() function, which explicitly excludes TranslatedResources that are from a system project. When one uses the field parameter and doesn't do any statistic fetching, the .stats_data() filters don't activate, which results in these 2 locales being included.

I believe that this type of distinction is not addressed in various other parts of the codebase, which leads to inclusion of bn-IN and bn-BD in many places.

[functionzz]

I believe that this type of distinction is not addressed in various other parts of the codebase, which leads to inclusion of bn-IN and bn-BD in many places.

This issue should be resolved with the merging of #3854.