typed ACS and transaction streams for Java codegen

[S11001001]

What is the problem you want to solve?

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

daml/language-support/java/bindings-rxjava/src/main/java/com/daml/ledger/rxjava/TransactionsClient.java

Lines 27 to 28 in a516be7

	Flowable<Transaction> getTransactions(
	LedgerOffset begin, TransactionFilter filter, boolean verbose);

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

daml/language-support/ts/daml-ledger/index.ts

Lines 998 to 1001 in 7657ba0

	async query<T extends object, K, I extends string>(
	template: TemplateOrInterface<T, K, I>,
	query?: Query<T>,
	): Promise<CreateEvent<T, K, I>[]> {

daml/language-support/ts/daml-react/defaultLedgerContext.ts

Lines 69 to 71 in a516be7

	export function useQuery<T extends object, K, I extends string>(
	template: Template<T, K, I>,
	): QueryResult<T, K, I>;

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. With #15125, 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.

[chunlokling-da]

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

I think the template / interface Companion will be the good place for these utility methods, agree?

[S11001001]

I think the template / interface Companion will be the good place for these utility methods, agree?

No, I think a static method on TransactionFilter would probably be better.

[chunlokling-da]

No, I think a static method on TransactionFilter would probably be better

How to access Companion in these method? by passing in as a parameter?

public abstract class TransactionFilter {
  public static TransactionFilter transactionFilter(ContractTypeCompanion<?, ?> contractCompanion , Set<String> parties) 
  {
    ...
  }
}

[chunlokling-da]

I have moved transactionFilter from TransactionFilter to ContractUtil, please review the PR