Add ENV variable for ConfigMap for adlists

[gattjoe]

Description

This change adds support for managing adlists with a ConfigMap in kubernetes. I modified _startup.sh to look for a CONFIGMAP_ADLISTS ENV variable. If found, it will call a new configmap_adlists shell script. In that script, I delete the entries for the adlists from gravity; then, I borrowed the database_table_from_file function from gravity.sh to import the adlists. Currently, it is a separate instance of that code; however, I think there can be a way to import it from gravity.sh so the code stays in sync.

Motivation and Context

I want to be able to manage adlists in kubernetes declaratively. Currently, if you mount a ConfigMap with an adlists file, it is only read into gravity on first boot and subsequent adds/deletes are not processed by pi-hole (by design).

This is definitely wet clay and the code can be hardened, but I didn't want to spend too many cycles if this is something the maintainers are not interested in accepting (or have a different / better approach in mind).

How Has This Been Tested?

I added / deleted adlists from a ConfigMap and restarted pi-hole to confirm that it deleted the old adlists from gravity and imported the new lists.

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• [x] My code follows the code style of this project.
• [x] My change requires a change to the documentation.
• [x] I have updated the documentation accordingly.

[gattjoe]

@PromoFaux bueller?

[PromoFaux]

Hi, thanks for the contribution. At this stage it is unlikely that we will release another v5-based image, excepting for minor bug fixes - new features should be based upon the development-v6 branch.

Defining adlists in a container is something I've often thought about, but then forgotten about thinking about further

[gattjoe]

fair enough, makes sense. What's the ETA for v6? I can refactor my code once its published.

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[PromoFaux]

What's the ETA for v6? I can refactor my code once its published.

Soon™ - but no actual date. Maybe by the end of September, maybe not!

However, the relevant code has now been merged into the development branch

[github-actions[bot]]

Conflicts have been resolved.

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.