typed ACS and transaction streams for Java codegen

[S11001001]

trafficstars

What is the problem you want to solve?

The highest-level subscription to read contracts we offer in Java looks like this:

https://github.com/digital-asset/daml/blob/a516be732849880c0d24586ab480c081f6da4472/language-support/java/bindings-rxjava/src/main/java/com/daml/ledger/rxjava/TransactionsClient.java#L27-L28

It requires

1. knowing how to assemble a TransactionFilter, and
2. knowing how to decode the result from Transaction.

By contrast, in TypeScript, we offer

https://github.com/digital-asset/daml/blob/7657ba0342959370867f752bbc1765653822714f/language-support/ts/daml-ledger/index.ts#L998-L1001

https://github.com/digital-asset/daml/blob/a516be732849880c0d24586ab480c081f6da4472/language-support/ts/daml-react/defaultLedgerContext.ts#L69-L71

This hides the mechanics of the relationship between template/interface IDs and the payload format, yielding decoded contracts as a result. Consider CreateEvent above, for example: instead of generic Record createArguments, the payload type matches what you queried.

What is the solution you would propose?

From codegen decoders #14313 , we can produce utility methods that

1. yield proper TransactionFilters for given party sets, with template or interface selected according to underlying contract-type-type, and
2. decoders to extract well-typed template payloads or interface views from transactions or ACS responses.

Moreover, these can then be combined into single utility calls to take ContractTypeCompanions and yield well-typed, decoded stream results.

Only a bare minimum of #14313 is needed for this feature: define FromValue, and define how it is derived from TemplateCompanion. Then it becomes possible to write and test the aforementioned utility methods. After that, we can consider interface support.

Describe alternatives you've considered

A single ContractTypeCompanion is sufficient to handle all sorts of single-interface or single-template streaming requests. For streaming multiple templates/interfaces at once, you need a combinator language to unify disparate payload types. This is similar to the problem of submitting multiple commands with the API proposed by #14312, and may invite similar thinking.

Additional context

When we decided to unify interface views and template payloads in JSON query, that yielded a TypeScript API that looked exactly the same from a user perspective as the present templates API. "Interface view is contract payload" is a nice way to transition from working with template payloads.

Moreover, while #14313 has been largely considered in terms of choice exercise utilities like #14329, it is equally useful for improving codegen integration into the bindings in this category.