Upgrade tofu provider versions

[mhajas]

Closes #1079

The purpose of the lock files is to have tofu versions part of the version control to be able to discuss versions upgrades in PRs. I think it makes sense to have the lock files there.

The source of the problem we have is that we don't specify/lock version of source modules in our modules:

keycloak-benchmark/provision/opentofu/modules/aws/accelerator/main.tf

Line 59 in 5061f0e

source = "terraform-aws-modules/lambda/aws"

This means tofu will always pick newest release and therefore load all new constraints from it.

There are more solutions to this:

1. Leave this behavior as is, detect wrong versions constraints by failed nightly run. The advantage is we will be always on newest versions, therefore we will be compatible for example with aws api. The problem is that manual work is needed all the time it breaks - since we use tofu this is the second time this occurs. Manual work that is needed is to run tofu init -upgrade in all modules - or at least in one that is failing.
2. Ignore locks and always use newest versions - we can remove lock files from git, run tofu init -upgrade in our scripts or have it configured globally in some env var. The problem here is that we can introduce some incompatibility by using a newer version of some provider, like aws, prematurely when some module is not yet compatible with it. Relaxed version of this could be to ignore the versions only for aws provider (the error happened both times with aws), the disadvantage is that tofu does not support this and we would need to manually change lock file by removing version line (this can be easily broken if someone commits the file after tofu init).
3. We can lock version also for module sources by specifying version below the line I sent the link to above. This would work, however, we risk some incompatibility if we use older version for some module. With 1. we at least can detect the constraint violation.

I would vote for 1. and this PR is updating the versions. However, I am open also to solution 3 but the disadvantage I see is that we can get errors from our nightly run and it could be hard to track from where the error comes from if there is some incompatibility by using older module for example, for aws lambda.

[ryanemerson]

+1 to go with option 1. If the build starts to break more frequently we can re-asses, but for now I think the advantage of having newer versions and not requiring manual upgrades is worth the risk.