feat: add inline auth middleware

[LucasRoesler]

Description

This feature adds an authentication middleware to the of-watchdog. The authentication logic is loaded from external OPA policy files, so that function authors can customize the auth logic.

This policy can even be loaded via a Secret.

This middleware is configurable via several new environment variables, the user can customize: the policy, set a list of paths to skip authentication, control what request content is passed to the policy during evaluation (headers, raw body, json body, additional secret values, additional env variables).

In addition to loading and evaluating plain OPA rego policy files, the middleware defines two custom functions to enable more secure policy rules:

1. bcrypt_eq exposes the bcrypt.CompareHashAndPassword method.
2. constant_compare exposes the subtle.constant_compare method.

Extensive documentation of the configurations and behavior are now included in the README. Additional, example policies for Basic Auth, HMAC, JWT, and OIDC flows are included in the auth/testdata as well as unit tests that demonstrate how those policies behave.

Motivation and Context

• I have raised an issue to propose this change (required)

If a function author is using a HTTP mode with a popular language and popular framework, they can probably implement this logic directly in the function. Adding it in the of-watchdog middleware means that:

1. policies can be applied easily in all modes, for example forking and static modes will more easily support advanced auth flows like OAuth and OIDC.
2. OPA Rego is language agnositc, so the same policy can be published and shared for any template or language. This reduces the complexity of ensuring that different functions are actually implementing the same policy rules because there is only one implementation.

OPA was chosen because it is part of the CloudNative landscape as a Graduated project and, for example, it is used by Istio.

How Has This Been Tested?

I have tested it locally with various test functions and via unit tests

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I've read the CONTRIBUTION guide
• I have signed-off my commits with git commit -s
• I have added tests to cover my changes.
• All new and existing tests passed.