Cache the internal CR token to avoid jumbox reconciliations

[nacx]

Fixes https://github.com/tetrateio/tetrate-service-bridge-sandbox/issues/241

@smarunich this is an absolute hack, but WDYT about this?

The idea is that just because that module uses an external script and always runs, it's altering the suer-data and causing the jumpbox to reconcile, when that's useless because cloud-init is run only on the first boot; changes to user-data wouldn't even be considered.

This change basically caches the initial token in the local filesystem to return it in subsequent runs, and avoid that annoying reconcile that breaks the development version usage.

I also considered adding it as an output variable of the module and propagate the output so it can be cached in the terraform state, and read with the terraform_remote_state data provider, but that would fail on the first run when the key still does not exist, so I opted for the local (.git-ignored) file hack. WDYT?

[smarunich]

I think it is good, technically we can expand to use https://developer.hashicorp.com/terraform/language/state/remote-state-data#defaults just for the sake... interesting if it works using default value :) ... or if that does not work simply the default empty using try https://developer.hashicorp.com/terraform/language/functions/try ... but also an experiment... to leverage terraform_remote_state, but not a big deal in my opinion for this case.

[nacx]

I've tried the remote_state thing but it doesn't work. even if I configure the defaults or use the try block, it fails on the first run with:

No stored state was found for the given workspace in the given backend.

I don't think this can be achieved with the state as I haven't found a way to have the data provider not fail if the file does not exist.