Optimize tags dashboards

[mathjazz]

Fix #2264.

I rewrote the code for retrieving data used on all three Tags dashboards:

• http://localhost:8000/projects/firefox/tags/
• http://localhost:8000/projects/firefox/tags/browser/
• http://localhost:8000/sl/firefox/tags/

I also:

• dropped the unused code (which represents the vast majority of changes in this patch)
• added an extra DB index, which significantly impacts Tags tab performance

The functionality should remain identical, but the views should be significantly faster. In the case of Firefox Tag dashboards, the load times were in the 20-30 second range (or timing out), now these pages take max. 2-3 seconds to load.

Deployed to stage.

[eemeli]

Only one minor stylistic quibble inline about the code, but I have two larger concerns:

1. The tests for the old implementation are removed, but I don't see any corresponding tests being added for the new class Tags. Is that really covered by the remaining prior tests?
2. The file paths and naming is messed up. TagsTool is now only used for the admin form, and it's in tags/utils/tags.py. Tags is the presumably more common non-admin part, and it's in tags/utils/utils.py. Could/should the former class and file be renamed as TagsAdmin or something similar, and Tags defined in tags.py?

[eemeli]

Suggested change

	if tr["approved_date"] is not None and tr["approved_date"] > tr["date"]:
	date = "approved_date"
	else:
	date = "date"
	dates[tr[date]] = tr[group_by]
	prefix = "entity__" if group_by == "resource__tag" else ""
	# Find translations with matching date and tag/locale
	translations |= Translation.objects.filter(
	Q(**{date: tr[date], f"{prefix}{group_by}": tr[group_by]})
	).prefetch_related("user", "approved_user")
	date = max(tr["date"], tr["approved_date"] or 0)
	dates[date] = tr[group_by]
	prefix = "entity__" if group_by == "resource__tag" else ""
	# Find translations with matching date and tag/locale
	translations |= Translation.objects.filter(
	Q(**{date: date, f"{prefix}{group_by}": tr[group_by]})
	).prefetch_related("user", "approved_user")

[mathjazz]

1. The tests for the old implementation are removed, but I don't see any corresponding tests being added for the new class Tags. Is that really covered by the remaining prior tests?

Codecov says the coverage of the utils.py is above 80% (although I can't currenty access the results page). Still, I should add a test or two for that.

2. The file paths and naming is messed up. TagsTool is now only used for the admin form, and it's in tags/utils/tags.py. Tags is the presumably more common non-admin part, and it's in tags/utils/utils.py. Could/should the former class and file be renamed as TagsAdmin or something similar, and Tags defined in tags.py?

OK, I'll move things around a little. Maybe rename tags/utils/utils.py to tags/utils.py and move the rest from tags/utils to tags/admin.

I didn't want to touch the old code before wiping it out the way I did with the rest of the code. I should file a bug for that.

I could also add a README file to /pontoon/tags/utils explaining that everything but the utils.py is legacy code that should not be touched.

[mathjazz]

Applied the suggested change, move Admin code to /admin and filed #3108.

[eemeli]

Suggested change

	from pontoon.tags.admin.exceptions import InvalidProjectError
	from .base import TagsDataTool
	from .base import TagsDataTool
	from .exceptions import InvalidProjectError