Revisit handling of nested inputs in call vs invoke

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

The code ported from C# has these notes:

            // This method backs all calls that generate
            // `Output<T>` and may include `Input<T>` values in the
            // `args`. It needs to decide which control-flow tracking
            // features are supported in the SDK and which ones in the
            // provider implementing the invoke logic.
            //
            // Current choices are:
            //
            // - any resource dependency found by a recursive
            //   traversal of `args` that awaits and inspects every
            //   `Input<T>` will always be propagated into the
            //   `Output<T>`; the provider cannot "swallow"
            //   dependencies
            //
            // - the provider is responsible for deciding whether the
            //   `Output<T>` is secret and known, and may add
            //   additional dependencies
            //
            // This means that presence of secrets or unknowns in the
            // `args` does not guarantee the result is secret or
            // unknown, which differs from Pulumi SDKs that choose to
            // implement these invokes via `apply` (currently Go and
            // Python) and is the same as C# SDK.
            //
            // Differences from `call`: the `invoke` gRPC protocol
            // does not yet support passing or returning out-of-band
            // dependencies to the provider, and in-band `Resource`
            // value support is subject to feature negotiation (see
            // `monitorSupportsResourceReferences`). So `call` makes
            // the provider fully responsible for dependency
            // tracking, which is a good future direction also for
            // `invoke`.

Some follow up work:

• it is possible that we do not need to support monitorSupportsResourceReferences=false monitors anymore, if that is true, some simplifications may be in order

• we need some tests to validate the choices java sdk is making here

Affected area/feature

Start by locating the Java SDK implementations of call and invoke, then read the handling around monitorSupportsResourceReferences and the C# port notes in this issue. Add tests that validate the Java SDK's nested Input, dependency, secret, and unknown handling; done means the supported monitor behavior and any simplifications are covered by tests.