We should support all features in mocks that we are supporting
otherwise. We did a similar thing in pulumi-dotnet:
https://github.com/pulumi/pulumi-dotnet/pull/93.
However here we're not simply changing hasSupport to true.
1e09626bc7
has a good explanation of why we only support specific values here.
However really we only need to disable support for `outputValues`, and
that only if output values are disabled. Originally this was true if
`PULUMI_ENABLE_OUTPUT_VALUES` was set, but that environment variable was
later inverted: 3027d01f25.
This ended up being a little bit more complicated than just passing
true, but I think it's more correct this way. I'm also happy to change
it back to just passing through `true` if that's preferred. Once we
decided on whether this is the right way to do it vs. just passing
`true` unconditionally I'll also update `java` and `dotnet` (if we're
going this way) to do the same.
Fixes#13355
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [ ] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [x] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
b5077dc7d3