refactor(map): refactor map.jinja

[sticky-note]

PR progress checklist (to be filled in by reviewers)

• [ ] Changes to documentation are appropriate (or tick if not required)
• [ ] Changes to tests are appropriate (or tick if not required)
• [ ] Reviews completed

---

What type of PR is this?

Refactor Map.jinja and templates

Primary type

• [ ] [build] Changes related to the build system
• [ ] [chore] Changes to the build process or auxiliary tools and libraries such as documentation generation
• [ ] [ci] Changes to the continuous integration configuration
• [ ] [feat] A new feature
• [ ] [fix] A bug fix
• [ ] [perf] A code change that improves performance
• [x] [refactor] A code change that neither fixes a bug nor adds a feature
• [ ] [revert] A change used to revert a previous commit
• [ ] [style] Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)

Secondary type

• [ ] [docs] Documentation changes
• [ ] [test] Adding missing or correcting existing tests

Does this PR introduce a BREAKING CHANGE?

No.

Related issues and/or pull requests

Describe the changes you're proposing

Pillar / config required to test the proposed changes

Debug log showing how the proposed changes work

Documentation checklist

• [ ] Updated the README (e.g. Available states).
• [ ] Updated pillar.example.

Testing checklist

• [ ] Included in Kitchen (i.e. under state_top).
• [ ] Covered by new/existing tests (e.g. InSpec, Serverspec, etc.).
• [ ] Updated the relevant test pillar.

Additional context

[myii]

@sticky-note This is going to be tricky to review because there is a lot going on in one PR, especially with everything squashed down into one commit. What I mean is that there are at least two separate activities here:

1. Replacing the old map.jinja with the new style from the template-formula.
2. Modifying all of the pillar.get calls to use the newly produced map.

Looking at the first point, we've also been having numerous discussions about our relationship with merging pillars into the map. Refer back to these links for more info:

• https://github.com/orgs/saltstack-formulas/teams/wg/discussions/21/comments/51
• https://github.com/orgs/saltstack-formulas/teams/wg/discussions/20

That part that is relevant to this PR: essentially we have three methods used across all of the formulas in this org:

1. Merge only the pillar lookup.
2. Merge the whole pillar.
3. Merge the lookup first and then the whole pillar on top.

So prior to this PR, this formula was method 1. This PR is changing it to method 3. We introduced method 3 in the first place to be a "catch-all" that worked with all formulas, but that doesn't look like a good idea going forward. We may end up maintaining method 1 as the ideal and there's a PR in progress that will allow us to choose the right option per formula:

• https://github.com/saltstack-formulas/template-formula/pull/186

So what does that mean here? I don't want you to lose your work but I will need you to split it for now, to make it easier to review and merge. There was a PR in the zabbix-formula recently, where I had to adjust the proposed change to map.jinja to only merge the lookup:

• https://github.com/saltstack-formulas/zabbix-formula/commit/36f980ed979a664adaa32863adad7c41e505d714#diff-fd733c35f79e84e81c75505e666c41c2L22-L28

Once we get that first refactor merged in, we can look at the rest of the changeset that you're proposing here.