Allow content matcher config in uptime checks

I'm proposing this as a BREAKING CHANGE due to the fact that it includes a complete refactor of the authenticated_health_check.py function which would cause production functions to be redeployed. With this in mind, once merged I'll create a v3.0.0 tag and v3 branch.

This MR fixes the following issues/adds the following features.

Closes #7 (closed)

Fixes

403 unauthorized errors when specifying a custom check endpoint

When specifying a custom check endpoint (local.uptime_check.path) in addition to using the authentication proxy function (local.authentication_proxy.enabled), I've found that the function returns a 403 Unauthorized error. I've tracked this down to the fact that the current function implementation is passing the full url (including the path) to the id_token.fetch_id_token() function, however in an example of service-to-service authentication in the documentation there is a comment mentioning that the second parameter for the id_token.fetch_id_token() function is in fact the audience, which for Cloud Run services should be the service's hostname without a path (i.e. https://my-cloud-run-service.run.app/). Therefore, I've refactored the function code to follow the example in the documentation which has resolved this issue in testing.

NOTE - To enable the content matching feature below, I've also amended the function so that it returns the actual JSON response from the Cloud Run endpoint (rather than a simple status code), allowing the uptime check (which calls the proxy function) to do the matching as required.

Features

Allow content matching as part of the uptime check config

The Digital Admissions team would like to use JSON content matching with a custom uptime check. Rather than implement this separately, I've included a new, optional, var.content_matchers variable.

Include an optional uptime check id in display names

The names generated by the current module clash if you try to deploy more than one uptime check for the same Cloud Run Service. With this in mind, I've added a local.uptime_check.id optional variable to be able to identify resources more easily.

Allow specifying existing Notification Channels

Currently, the module accepts an optional list of email addresses which it will create a new Notification Channel for each and configure alerts to be sent. However, this is not a very elegant solution so I have added the var.alert_notification_channels variable which allows specifying existing Notification Channels (by ID) as well as the previous var.alert_email_addresses variable. The two are then concatenated and used to configure the alert policies.

Chores

• There are many changes in this MR so I have ensure that the README.md is up to date with the new options available.
• I'm using the opportunity of this breaking change to change the module "authentication-proxy" module call to use the preferred snake case module "authentication_proxy".