implement "callable updates" as "create and exercise" Ledger API command

[francesco-da]

Many people have expressed the desire of being able to define "top level updates" in their .daml files that they can call from their application.

While talking to @martin-drhu-da , it occurred to me that we can implement that easily with the existing infrastructure if we add a "CreateAndExercise" command to the Ledger API, which as the name suggests bundles a CreateCommand and ExerciseCommand in one go.

Then, the "top level update" can be implemented as a template that has the submitter party as only argument and signatory, and then a choice (or multiple choices) that contain the argument of the top level update.

cc @martin-drhu-da @neil-da @bame-da @andrae-da @filmackay

[gerolf-da]

@francesco-da: strictly speaking we cannot reuse the ExerciseCommand directly, because the user cannot fill the contract_id field with a sensible value.

We could add a dedicated "application service" request that ultimately will be converted to a CreateCommand and ExerciseCommand:

message CreateAndExerciseRequest {
  string ledger_id = 1;
  string workflow_id = 2;
  string application_id = 3;

  // should this rather be set by the application service itself?
  // or should this command_id be used for the exercise,
  // so the user could observe the final outcome separately on the
  // completions stream with this command_id
  string command_id = 4;  

  string party = 5;

  // maybe we only want the user to specify a TTL that is then used for both
  // the CreateCommand and the ExerciseCommand
  google.protobuf.Timestamp ledger_effective_time = 6; // 
  google.protobuf.Timestamp maximum_record_time = 7;

  Identifier template_id = 8;
  Record create_arguments = 9;
  string choice = 10;
  Record choice_argument = 11;
}

How do you want to handle failure scenarios?

Create	Exercise	Overall
Failed	-	Failed
Successful	Failed	Retry exercise n times (if applicable), then fail?
Successful	Successful	Successful, return the transaction tree? (trivial to implement after #406 and #479)

[gerolf-da]

Alternatively, we can implement the CreateAndExercise as an atomic set of LF create and exercise commands, although that means we'd need to open up command translation to relative contract IDs.

Edit: it seems like there are quite a few places in the engine that assumes only absolute contract ids, so we either open up relative contract ids again in general, or we go the compound-api-service route.

[gerolf-da]

Conclusion, similar to translateExercise, we'll create a method that produces an Update expression for both creating the contract and exercising the choice.

[bame-da]

I'm not sold on the value of this addition. You are saving developers a simple "check for existence and create the Action contract if it doesn't" step in the automation. You still can't get return values from Updates in the application layer and still can't access pure DAML functions.

[gerolf-da]

@bame-da: Return value from exercise is implemented by #479.

[gerolf-da]

you could then execute a pure function (in a slightly round-about way) in terms of a create-and-exercise.

[bame-da]

Yeah, but you get the side-effect of writing a transaction. Would it be so difficult to flip this around and allow evaluation of functions with serializable arguments and return type a or Update a, where a is serializable?
The semantics would be that functions of type Update a are submitted as a transaction.

[bitonic]

done, see #563