Pass apt_conf context variables to the template as json object

[jerrykan]

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?

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
• [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

Currently when passing the apt_conf context variable to the template the variables will not necessarily retain their correct type. An example of this would be when using a pillar value of null it would be passed to the template as the string "None" instead of type None.

If we pass the apt_conf context variables to the template using a json object the variables retain their correct types.

Pillar / config required to test the proposed changes

apt:
  apt_conf_d:
    'Acquire::http::Proxy::external.example.com': 'DIRECT'
    'Acquire::http::Proxy::oldexternal.example.com': null  # entry won't be created

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

[baby-gnu]

Hello.

Do you think this fix could be tested?

It may require a little bit of work like:

1. add an example in pillar.example
2. create a new Inspec profile looking like the unattended one