Introduce a retry mechanism for fetching files from the internet

## Problem statement

Sometimes the framework can receive a 4xx or 5xx HTTP error code when requesting a file (like a manifest) in order to deploy/teardown an add-on. These in most cases are intermittent and should be retried since as a developer I do not want to have my full suite of tests to fail because Github returned a 503.

Example of a failed CI: https://github.com/Kong/kubernetes-testing-framework/actions/runs/3647089054/jobs/6158901046

```
=== RUN TestKongWithNodePort
kongaddon_test.go:243: configuring the testing environment, with the kong addon using NodePort service type for proxy
kongaddon_test.go:248: building the testing environment and Kubernetes cluster
20[22](https://github.com/Kong/kubernetes-testing-framework/actions/runs/3647089054/jobs/6158901046#step:6:23)/12/08 09:48:52 well-defined vars that were never replaced: SERVICE_NAME,SERVICE_NAMESPACE
kongaddon_test.go:250:
Error Trace: /home/runner/work/kubernetes-testing-framework/kubernetes-testing-framework/test/integration/kongaddon_test.go:[25](https://github.com/Kong/kubernetes-testing-framework/actions/runs/3647089054/jobs/6158901046#step:6:26)0
Error: Received unexpected error:
failed to deploy addon kong: Error: INSTALLATION FAILED: failed to fetch https://github.com/Kong/charts/releases/download/kong-2.13.1/kong-2.13.1.tgz : 503 Service Unavailable
: exit status 1
Test: TestKongWithNodePort
--- FAIL: TestKongWithNodePort (138.36s)
```

Start with test/integration/kongaddon_test.go around the reported failure, then trace the add-on file-fetching path used during deployment and teardown. Review how 4xx and 5xx responses are handled; done means intermittent errors such as the reported 503 are retried instead of failing the integration suite.

Written by the indexing model from the issue text.