core: fix dockerfile secrets in modules by making secret pure

[sipsma]

The use case of:

1. Building Dockerfiles via the Container.build or Directory.dockerBuild APIs
2. That have secrets attached
3. That were created by modules and returned as Container values

Appears to have been broken for a while.

Before the secret isolation in v0.12.1, it was broken because these returned Dockerfiles were re-evaulated when the core ID was loaded after the function returned but the accessor was calculated again based on the caller, which resulted in a different secret value and thus missing secrets when the Dockerfile evaluation got unlazied.

After v0.12.1, the error changed to be a bit earlier, but still happened as the core ID for the returned Dockerfile build was being loaded. It now was happening because the Container.build implementation synchronously looked up secrets before they had been identified and passed from the function call client to the caller's secret store.

The fix here is deceptively simple: just don't mark secret as impure anymore. It's no longer necessary to do this because of the changes made in v0.12.1. Whereas previously secret actually looked up and calculated the accessor in some codepaths, it now just returns a static value based purely on the inputs.

The reason this fixes the issue is a bit subtle and honestly might be a bit shaky; worth more thought. It's because when secret is pure, the whole dockerBuild API doesn't get cache invalidated and thus allows loading the return value to rely on dagql caching and skip the part where we were synchronously trying to find secrets that weren't loaded yet.

Instead what happens now is the value gets loaded but returned from the cache, which allows the passing of secrets from the function call client to the caller to happen. Then when the Dockerfile-built Container is evaluated, the secrets will indeed be there.

Some more details in this comment: #8035 (comment)

---

Fixes #8035

This does appear to fix the issue based on the integ test added and the other secret tests I ran so far seem unimpacted.

However this is such a subtle one-line change that I want to digest it a little more and at minimum probably add even more integ tests to ensure every possible corner case is exercised. Marking as a draft pending those extra tests.

EDIT: after thinking some more, it still makes sense to me. Expanded the test coverage a bit more too to test evaluation from both within the module and on the cli client side

[helderco]

This fixes the use case in the docs (pending docs fix that I'll submit). 👍