terraform-dynamic-python-webapp Bug: infra tests don't include CSRF/POST tests

Issues like https://github.com/GoogleCloudPlatform/avocano/issues/269 would have been detected earlier if the infra tests were able to do testing on POST commands.

If CSRF is not setup correctly (and debugging is enabled), a very obvious Django error occurs

Avocano server tests use http requests and cookies to log into the Django Admin, testing a POST request https://github.com/GoogleCloudPlatform/avocano/blob/main/provisioning/test/server_test.py#LL23C10-L23C10

Client tests use playwright for more interactive testing, but essentially also creating a POST request https://github.com/GoogleCloudPlatform/avocano/blob/main/provisioning/test/client_test.py#L36

Jun 16 '23 05:06 glasnt

I think the Avocano repository remains the place for deep tests that the application behaves as expected. Our challenge is that the deployment process in this repo impacts the application behavior, especially around things such as networking, authentication, and uncaught partial deployment failures.

I propose the fix is to inject part of the Avocano testing process into this repositories test process:

Inside int.cloudbuild.yaml, add step(s) for app testing after simple-example-verify. (It's unclear we need both simple and suffix test cases for the Avocano tests, but we could do both)
Clone the avocano repository (read-only mode is fine, 0 depth is fine. Use the Avocano release tag configured in the branch under test.
Duplicate or directly run test.cloudbuild.yaml from the Avocano repository. (Reuse is less code, but may have path complexity and may be challenging to maintain compatibility from the Avocano side.)
The build step that runs the Avocano tests can fail this repo's tests just as well

From my inspection of the Avocano tests, the tests themselves identify relevant URLs so all we need to do is point them at a project. Supporting suffix deploy may require some new configuration options.