[BUG] Remove client track specific code coverage and javadoc build targets from the aggregate pom structure files

[JimSuplizio]

The root pom ./pom.xml was modified to have jacoco and javadoc build rules for client track libraries and every client track ServiceDirectory/pom.xml was modified to have jacoco build rules for client track libraries. The reason why this is a problem is that these now contain actual artifact tags for the plugins which do not get verified as part of the pom file verification because only things that have the pom client parent are verified due to too many random track 1 poms that we can't verify. Because of this, there are issues with version updates not correctly being done which other people are running into that are causing a lot of confusion.

The root ./pom.xml and ServiceDirectory level pom.xml files are not supposed to contain anything other than aggregation which is to say everything in the tags and nothing more.

The service directory pom files are being used to create the code coverage rollup and the root ./pom.xml is being used to also create a coverage rollup as well as a docs rollup. What needs to happen is something similar to what we're doing for the FromSource runs which is to generate the POM file on the fly. This will also eliminate the plugin version discrepancies. The generate_from_source_pom.py script is an example that should be close enough to steal most things from but since you're going to require a specific artifacts list, the usage of verify_release_set.ps1 inside of the archtype-java-release-batch.yml is a good example of passing in the full artifacts list to a script.

[github-actions]

Hi @JimSuplizio, we deeply appreciate your input into this project. Regrettably, this issue has remained unresolved for over 2 years and inactive for 30 days, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.

[JimSuplizio]

This appears to have been fixed by @srnagar with his changes in the following PR