feat: support loading secrets when only present in dotenv

[haddowg]

Please see the related PR on the secrets loader which adds support for defining secret env values in dotenv.

This change ensures we will always attempt to load secrets if the secret-loader is a dependency, as there may be no secret values (bref-ssm:...) in the lambda directly but there may be some in a dotenv file.

We keep the check for un-loaded secret values after the loader has run (if it was present) for cases where the dependency was missing or where the secret loading has somehow failed.

[GrahamCampbell]

I don't think this makes sense, as we explicitly wanted to throw the exception to let people know, instead of this silently failing. If we did want to change that behaviour, you'd also need to delete lines 30-34.

[haddowg]

I don't think this makes sense, as we explicitly wanted to throw the exception to let people know, instead of this silently failing. If we did want to change that behaviour, you'd also need to delete lines 30-34.

The suggested changes do not alter this behaviour, it will not silently fail, and will still throw an exception if the dependency is missing but you have a bref-ssm: prefixed env value.

If the dependency is present it will load the secrets the bref-ssm: prefixed values will no longer be present and it will return.

If the dependency is missing and you have no bref-ssm: prefixed values then it does nothing as previously.

[GrahamCampbell]

Ah, I see.

[GrahamCampbell]

Probably we should add a test to validate this.

[haddowg]

Probably we should add a test to validate this.

Happy to, but not sure how practical that will be as the secret loader is a dev dependency currently.

Could remove it and change the ::class references to a local string constant and use call_user_func? Phpstan might not like that.
Let me know if that would be acceptable.