Add missing configuration/features to Smithy build plugin

[robin-aws]

The number and complexity of CLI arguments are getting out of hand. We already have an alternate interface into the code generation logic as a Smithy build plugin, which supports configuration via a smithy-build.json. It also supports standard Smithy features such as projections because it hooks into the full Smithy model building pipeline.

This task is to add the missing necessary configuration knobs to our smithy-build.json configuration handler so that we can migrate off the CLI.

(More specific design for how these options should map to smithy-build.json configuration pending...)

[robin-aws]

Note the scope of this issue is only for CLI options that are relevant in --aws-sdk mode, since we only have the dafny-client-plugin plugin so far. Some options will only be needed for the dafny-library-plugin we have yet to create: https://github.com/smithy-lang/smithy-dafny/issues/153

[robin-aws]

Here is some more detail on the scope of this task vs. future ones.

One key difference between the CLI and the Smithy build plugin is how they use input and output. The CLI has options like --library-root pointing to the source code directory, and options like --output-java that allow it to write code anywhere on disk. The Smithy CLI/Gradle plugin only gives Smithy build plugins parsed/resolved/validated Smithy models as input, and expects output to only be written to a build directory like build/sources/dafny-client-plugin.

I believe the best way to bridge this gap is with an additional shared Gradle plugin that can be executed after invoking the smithy-gradle-plugin task to build a model. This plugin would provide the connection between the contents of a directory that the Smithy build plugin outputs like <project-root>/build/sources/dafny-client-plugin/runtimes/java/smithy-generated and where that code is checked in, i.e. <project-root>/runtimes/java/smithy-generated. The --patch-files-dir and --update-patch-files features of the CLI would also move to this plugin.

The plugin would have three different tasks (or at least modes of a single task):

• assert-same - apply patch files, then assert that the two locations have the same content
• update - apply patch files, then copy from the build directory on top of the checked-in directory
• update-patch-files - don't apply patch file, update them to match the difference between the build directory and the checked-in copy

It looks like this is the only missing "feature" to make this work. For the record here is the analysis I did of the current set of CLI options:

CLI options that need new smithy-build.json equivalents

• --patch-files-dir/--update-patch-files
  • Should be handled by post-processing

CLI options that already have smithy-build.json equivalents

• --model
  • Maps to sources
• --namespace
  • Maps roughly to service: the Smithy build plugin tells the code generation logic to generate for all shapes in the namespace of the identified service
• --library-root
  • Always the plugin artifacts output directory (i.e. build/sources/dafny-client-codegen)
• --dafny-version
  • Maps to plugins.dafny-client-codegen.dafnyVersion
• --include-dafny
  • Maps to plugins.dafny-client-codegen.includeDafnyFile
• --properties-file
  • Always set to <output directory>/project.properties
• --output-dafny/java/dotnet/...
  • Target languages are selected via a plugins.dafny-client-codegen.targetLanguages list instead
  • Output locations are fixed for the Smithy build plugin, see above about post-processing
• --aws-sdk
  • Implicitly always true for dafny-client-plugin
• --java-aws-sdk-version
  • Intentionally not supported: defaults to V2, V1 not used

CLI options not yet relevant (because they will apply to dafny-library-codegen instead)

• --dependent-model
• --local-service-test