chore(cleanup-docs): deleted last-remaining deprecated files and folders

[VRamakrishna]

• Completed the documentation cleanup process that was started in https://github.com/hyperledger/cacti/pull/3391 but which left some unneeded files because of conflicts with https://github.com/hyperledger/cacti/pull/3390 and https://github.com/hyperledger/cacti/pull/3389.
• Updated package versions in Weaver tutorial docs.
• Now the docs folder is the sole repository for Cacti documentation.
• Also upgraded com.jfrog.artifactory versions in build.gradle files as the old version had a missing dependency and was causing build failures.

Pull Request Requirements

• Rebased onto upstream/main branch and squashed into single commit to help maintainers review it more efficient and to avoid spaghetti git commit graphs that obfuscate which commit did exactly what change, when and, why.
• Have git sign off at the end of commit message to avoid being marked red. You can add -s flag when using git commit command. You may refer to this link for more information.
• Follow the Commit Linting specification. You may refer to this link for more information.

Character Limit

• Pull Request Title and Commit Subject must not exceed 72 characters (including spaces and special characters).
• Commit Message per line must not exceed 80 characters (including spaces and special characters).

A Must Read for Beginners
For rebasing and squashing, here's a must read guide for beginners.

[VRamakrishna]

I don't know why this test and others like it (i.e., exercising similar modules) is failing: https://github.com/hyperledger/cacti/actions/runs/10006846343/job/27663333818. I'm trying the same build in my local setup and it works. Also, I can't find the last time that test worked, because all recent PRs (until recent ones) have skipped these tests.

Does anybody have any ideas?

[petermetz]

I don't know why this test and others like it (i.e., exercising similar modules) is failing: https://github.com/hyperledger/cacti/actions/runs/10006846343/job/27663333818. I'm trying the same build in my local setup and it works. Also, I can't find the last time that test worked, because all recent PRs (until recent ones) have skipped these tests.

Does anybody have any ideas?

@VRamakrishna It fails with downloading some java dependencies from the jfrog artifactory. I've seen similar failures before that turned out to be just outages on the side of jfrog where the CI job failed to get the dependencies because their (JFrog's) servers were down. Other times GitHub's data centers have some networking issue and it fails to download it just because the connection from Azure to JFrog is broken and you locally can still install things because the connection between your house/office to JFrog is working still.
My first guess is this and I usually just wait 1 to 2 days for the issue to fix itself before I re-run the tests and see if it works. If that doesn't help then I go deeper and investigate but 99% of time it's something like this.

One more thing to consider and try: wipe your local maven/gradle dependency caches and try again the build locally. It could be that on your machine it works only because past successful builds have cached the dependencies but the CI with the freshly provisioned ephemeral workers that run the jobs do not have the cache pre-warmed and so it could be failing because it's trying to download the dependency while your personal computer isn't fetching it at all.

[VRamakrishna]

@petermetz I upgraded the version of the offending package (which in turn had a dependency that Maven seems to have removed.) The tests are re-running now. If everything works, I'll rebase and merge.

[petermetz]

@petermetz I upgraded the version of the offending package (which in turn had a dependency that Maven seems to have removed.) The tests are re-running now. If everything works, I'll rebase and merge.

@VRamakrishna Oh, that's an interesting one. My charitable interpretation there would be that the versions that got removed had some very severe vulnerability in them and this is how they forced an upgrade for everyone, but I'm not aware of any CVEs like that right now so who knows why would they just remove specific versions of dependencies. Thank you for fixing it!
In the meantime I PR'd v2.0.0-rc.3 with the merge freeze but I'm more than happy to issue an RC.4 right after too (with this fix in it)

[petermetz]

@VRamakrishna How did you manage to merge this with the freeze in effect? I wonder if the mergefreeze check is buggy.