Relax serialized project cache checks

[sdedic]

The idea in #3375 to check the global Artifact store was good in general, BUT ...

it turned out that when the project is loading in FULL_ONLINE mode (implies no --offline switch), the NBTooling plugin will not report back any javadocs or sources even though they may exist in the local ~/.gradle jar cache. OK, after that the project is saved without any such artifacts, and the artifact store is updated with this imprecise info: no sources / javadocs would be registered (so eventually sources/javadocs maps can be completely empty). Consider, for example, if the var/cache in userdir is cleared, but the gradle (~/.gradle) caches are intact.

In some future run of the IDE, the project is fetched from the cache (without any source / javadoc), but GradleModuleFileCache21 can find them from their binary .jar - and the cached project is deemed invalid as info in IDE's artifact store differs from the gradle's caches. So, the project is not loaded from the cache, but again through Gradle daemon. This time, the FULL level is sufficient - and that one will load even source + javadoc info - that's stored in the project cache AND in the artifact store. But if eventually the project file contains some real problems and ONLINE mode activates, no source/javadoc update goes to the artifact store.

In addition, there are BOM-like projects, which do not have any binaries, just pom, for example. Such projects are always rejected, as binaries are always empty. It is sufficient for a project to have a dependency on just one POM-like module for the disk cache to be rejected.

This PR relaxes the checks, assuming that if the project does not contain any info for sources | javadocs, it's OK. The info will eventually accumulate. The jar/binary is still used to detect inconsistency between the cached state and gradle cache: if the cached project does not contain JAR artifacts, which are in gradle local cache, the project is most probably wrong and should be reloaded.

The PR improves diagnostics by logging problems encountered during project load; problems are printed with FINE level, so one could find out why a project is reloaded, not cached etc.

During debugging, I've found out that certain resolution errors are reported in offline mode as problems - but do not throw an exception that is caught in LegacyProjectLoader and cause re-load in online mode. The tooling now throws a specific exception in such case that is allowed to pass to the Loader.

[lkishalmi]

Let me add some history on this.
So at the initial phase of the Gradle plugin, all JavaDoc and Source information was retrieved directly by the tooling plugin. These are treated as miscellaneous information. They are not serialized along the other project information,rather than kept a globally serialized artifact store updated.

With the introduction of the GradleModuleFileCache21 the globally serialized artifact store could be redundant, as the javadoc and source information could be retrieved directly from the cache.

So probably it would be wise to revisit the handling of this information and remove some code.

[sdedic]

Yes, the description is misleading / wrong sorry; I am still working on some scenarios where serialized project is rejected despite the data in artifact store are still valid. For now just ignore the description - will update :) before going from draft stage.

Or do you mean the whole concept of the artifact store is superseded by the GradleModuleFileCache21 ?

[lkishalmi]

Or do you mean the whole concept of the artifact store is superseded by the GradleModuleFileCache21 ?

Yes. I think that's possible. At the moment I can't name any use-case where GradleModuleFileCache21 with additional heuristics for Maven and File dependencies would not be enough.

[sdedic]

Consolidated; description updated.

So probably it would be wise to revisit the handling of this information and remove some code.

It could be much better, but we are about to release vscode in a few weeks, and I'd rather not to disrupt things. So far the changes made here are pretty local, not affecting other things than the loading process - and greatly improve project loading time.

Let's do the cleanup in a separate PR.

[ppisl]

I don't see anything problematic in the changes. I have also checkout the branch a little bit play/tested the funtionality and it seems to be ok.