Implement WAFPolicy controller

[ciarams87]

Proposed changes

Problem:
As a user of NGF
I want NGF to fetch my NAP WAF Policy bundle from a remote location and I want my WafPolicy configuration applied to NGINX for the Gateway or Route scope and
So that that this bundle can be applied and I can enable WAF protection on my traffic

Solution: Implement the policy fetcher and the WAFPolicy controller.

This solution deliberately omits status, polling, and authentication, as they will be done in future PRs.

Testing: Over 90% unit test coverage, added and extended BDD tests where appropriate, and manual testing in a GKE cluster

Please focus on (optional): I split out the crd, image, and RBAC fixes, as well as the policy fetcher into separate PRs. The WAFPolicy controller code is the final commit in this PR, as it depends on the functionality in the other PRs.

Closes: #3454

Checklist

Before creating a PR, run through this checklist and mark each as complete.

• I have read the CONTRIBUTING doc
• I have added tests that prove my fix is effective or that my feature works
• I have checked that all unit tests pass after adding my changes
• I have updated necessary documentation
• I have rebased my branch onto main
• I will ensure my PR is targeting the main branch and pulling from my branch from my own fork

Release notes

If this PR introduces a change that affects users and needs to be mentioned in the release notes,
please add a brief note that summarizes the change.

NONE

[tataruty]

i would move securityLogs and BundlePath fields creation to separate methods to increase visibility

[ciarams87]

Thanks for the feedback!

I'm not sure I see the value in splitting the logic into further smaller functions though - this function is already fairly small and on the lower side in complexity. Splitting it out might create more functions to maintain without meaningfully improving readability. Do you have any specific visibility concerns?

[tataruty]

Yes. First of all 50 lines - it is not a small function :D
For Go with all those err checks it usually should be not more than 20 lines, with some exceptions.
Also, according to classical https://github.com/Gatjuat-Wicteat-Riek/clean-code-book/blob/master/Clean%20Code%20(%20PDFDrive.com%20).pdf it should be not only short, but also do only one thing in the function. Of course at the first sight this method does one thing: generates Policies files, but inside of it it generates fields, that already should be moved to separate method, then inside of fields generation it has not one-line logics for BundlePath and SecurityLogs fields, those inside have additional maps and cycles.
All that together makes reading the code a bit messy.
Changing the code isn't done the same often as reading, so, maintainability will be still easy.
It is like writing monolith and microservices: easier to understand login and maintain.