[Resolve #937] Reset Jinja2 variable cache between config files

[alex-harvey-z3q]

From https://github.com/NathanWilliams

I am adopting this stale PR:
#938

---

Fix for: #937

This resets the Jinja2 templating_vars in config/reader.py to prevent variables leaking across StackGroups.

Without this patch applied, the test case added would fail and show param1 from stack_group_config1 has leaked into stack_group2:

E             Full diff:
E               {
E                'j2_environment': {},
E             -  'param1': 'value1',
E                'param2': 'value2',
E                'var': 'initial_value',
E               }

Nathan's fix is shown to prevent this unintended behaviour.

PR Checklist

• Wrote a good commit message & description [see guide below].
• Commit message starts with [Resolve #issue-number].
• Added/Updated unit tests.
• Added/Updated integration tests (if applicable).
• All unit tests (poetry run tox) are passing.
• Used the same coding conventions as the rest of the project.
• The new code passes pre-commit validations (poetry run pre-commit run --all-files).
• The PR relates to only one subject with a clear title.
  and description in grammatically correct, complete sentences.

Approver/Reviewer Checklist

• Before merge squash related commits.

Other Information

Guide to writing a good commit

[zaro0508]

The issue for this hints that using a non deterministic set is the problem...

If a variable is omitted in one stack group's config, 
the incorrect value from another group is used.
(Note: Sceptre uses a set for its file list, which is non-deterministic,
as such the following bug will only be seen on some runs)

I'm wondering if the better fix is to use an more deterministic data structure, like a ordered set?

[alex-harvey-z3q]

I'm wondering if the better fix is to use an more deterministic data structure, like a ordered set?

@zaro0508 That's not a fix for this bug but it would have assisted the original team who reported the bug in being able to consistently reproduce it. The nature of the bug here is simply that keys belonging to other stack groups leaked into the configs of stack groups they did not belong to and this would occur with or without ordering. Maybe track a separate issue of making the code a bit more predictable by using ordered sets where applicable?