extractor: subscribe to multiple parties

[S11001001]

The extractor --party option may now specify multiple parties, separated by commas; e.g. instead of --party Bob you can say --party Bob,Bar,Baz and get the contracts for all three parties in the database.

Fixes #1353.

Pull Request Checklist

• Read and understand the contribution guidelines
• Include appropriate tests
• Set a descriptive title and thorough description
• Add a reference to the issue this PR will solve, if appropriate
• Add a line to the release notes, if appropriate

NOTE: CI is not automatically run on non-members pull-requests for security
reasons. The reviewer will have to comment with /AzurePipelines run to
trigger the build.

[leo-da]

@S11001001 I will give it a more thorough review on Tuesday... but so far I don't see changes in the com.digitalasset.extractor.config.ConfigParser to support multiple parties. It still says it is a String, needs to be Seq[String]

      opt[String]("party")
        .required()
        .action((x, c) => c.copy(party = x))
        .text("The party whose contract data should be extracted.")

I would also make it plural: "parties"

[bitonic]

@leo-da I think we should keep --party. @S11001001 my preference would be to be able to mention --party multiple times, because you can have spaces in parties.

[bitonic]

Looks good, but please add a tests that ensures we can use parties with spaces in them.

[remyhaemmerle-da]

Nice.

[leo-da]

@S11001001 @bitonic I don't think it will work with multiple --party parameters, --party has to be: opt[Seq[String]] to support one or more.

[leo-da]

@S11001001 @bitonic I don't think it will work with multiple --party parameters, --party has to be: opt[Seq[String]] to support one or more.

actually it has to be unbounded:

  /** Allows the argument to appear multiple times. */
  def unbounded(): OptionDef[A, C] = maxOccurs(UNBOUNDED)

[S11001001]

my preference would be to be able to mention --party multiple times, because you can have spaces in parties.

@bitonic Not sure how these are related; parties are comma-separated in this PR, not space-separated.

[S11001001]

@leo-da This is the splitting you were looking for; I have a weak preference for doing as little parsing into CliParams as possible, but do you want me to add moar type safety for CliParams?

[leo-da]

nah, it is fine... but my main concern was documentation, the help screen. Plus the thing that @bitonic wanted you need unbounded option configuration, to support multiple party options.

[S11001001]

Docced in 1c2cb89

[S11001001]

Looks good, but please add a tests that ensures we can use parties with spaces in them.

@bitonic Added in b78174d; thanks.

[leo-da]

my preference would be to be able to mention --party multiple times, because you can have spaces in parties.

@bitonic Not sure how these are related; parties are comma-separated in this PR, not space-separated.

@S11001001 I think @bitonic wants to support spaces in the Party names like:

--party "Party A with spaces" --party "Party B with spaces"
or maybe:
--party "'Party A with spaces','Party B with spaces'"

[S11001001]

@leo-da I understand that, but as you noted --party "Party A with spaces,Party B with spaces" suffices for that, so I'm not sure why spaces-in-parties entails passing the --party option multiple times.

[bitonic]

@S11001001 I find spaces + commas quite awkward. in any case, this is ok for now.

[S11001001]

@leo-da I'd appreciate a re-check as I've changed the design to be closer to what you might have been looking for, so we have better command-line error reporting (doesn't just pass malformed parties through to API). I've also created an exciting new merge conflict for your #1361 🎉

[leo-da]

LGTM