feat: generate showcase without post-processing

[diegomarquezp]

Modifies the logic of #1916 to support generation of showcase

NOTES

• Referencing an external repository as the source of the protos when building showcase makes the proto folder to contain a path that includes the external reference. Googleapis-based generated libraries do not contain this difference (example) but instead contain the proto_path (i.e. path from repository root to proto location).
  • To fix this, I added an extra postprocessing step in the current showcase generation
  • I also tried modifying the bazel BUILD file to copy the protos into showcase but it produced a similar result - a path like proto/bazel-out/.../schema/....
• The enable-golden-tests profile was updated so it compares the current source code of showcase against a recently generated library via the hermetic build scripts.
• The verify profile calls the new scripts without merging them into the current showcase source and running a diff to confirm nothing has changed

PENDING

• use current snapshot of gapic-generator-java to generate showcase (currently uses a published version)

[meltsufin]

Can we keep all of these folders in a temporary directory because when the script fails midway and cleanup is skipped, it's petty messy? It would be easier if there was a subdirectory under showcase like build that contained all of this.

[blakeli0]

+1. Similar to the temp bazel folders like bazel-out when we were using bazel.

[diegomarquezp]

@meltsufin would it make sense to have a separate PR for this? This will also affect the main generation scripts (cc: @blakeli0 )

[blakeli0]

Now that we are generating all three modules at the same time, is it possible to have a diff for all three modules?

[diegomarquezp]

Unless there is a better way than preparing two special folders with a similar structure and run diff on their roots I think the simplest is to just run diff one time for each of the folders (proto, gapic and grpc) in a single call to verify.sh. We don't compare all the contents of gapic-showcase or grpc-gapic-showcase-v1beta1 because there are other special files not generated by the scripts (e.g. ITs).

[blakeli0]

+1. Similar to the temp bazel folders like bazel-out when we were using bazel.

[meltsufin]

You follow up on the outstanding comments in a separate PR.

[blakeli0]

LGTM. It would be better if we can add unit tests for new utility functions as @JoeWang1127 mentioned if it's not too much, otherwise it's OK to add it in another PR.

[diegomarquezp]

LGTM. It would be better if we can add unit tests for new utility functions as @JoeWang1127 mentioned if it's not too much, otherwise it's OK to add it in another PR.

Thanks @blakeli0 and @JoeWang1127 . I added a couple tests for info extraction functions.

[sonarqubecloud]

[java_showcase_integration_tests] Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[sonarqubecloud]

[java_showcase_unit_tests] Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[sonarqubecloud]

[gapic-generator-java-root] Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication