Revert "Use the tag_list method, rather than the cached_tag_list attribute"

[djuber]

Reverts #15638

Non-critical - but the performance did decrease more than my limited local testing suggested it would.

https://ui.honeycomb.io/thepracticaldev/datasets/rails/result/5v8bxRJqoBy

Comparison with the day before versus after 15638 deployed:

This job (Follows::UpdatePointsWorker) is now taking between 0.5-2.0 seconds - we run it about 7000 times a day (averaging to about every 10 seconds), so it's not a huge problem, but it's a bigger regression in performance than we should accept uncritically

[citizen428]

This is what I was afraid of :-( Can we easily revert this or will this bring back a problem that the previous PR will revert? Also, is this performance regression something critical or can we live with it?

[djuber]

Ah - this is

1. something we can live with (the performance regression is acceptable for how often the job runs) - that's my personal gut feeling and can be invalidated by any counter-opinion.
2. something we can safely revert without worry - the issue may have been test only and resolved separately (in a change to the test case) - I don't think we're seeing cases in practice/production where an article doesn't have the cached_tag_list column set correctly.

[maestromac]

my gut feeling based on this 14 days heatmap is it's a tolerable performance loss. The performance loss is not very noticeable.

[jgaskins]

Agreed with @maestromac. There are a few outliers but they're acceptable. Also, those outliers started a full day after that PR was merged, with thousands of reactions created in that time.