feat: Clean cache command

[d3xter666]

The command completely cleans the cache by removing the cache files as well as cleaning up the SQLite records.
It does not wipe out the SQLite DB file(s)

JIRA: CPOUI5FOUNDATION-891

[RandomByte]

It seems odd that this file is placed next to the other files responsible for managing the framework packages but doesn't use any of them. I would expect better integration here, e.g. no hardcoded assumptions like the framework/ directory name as well as checks for existing lockfiles to prevent deleting files while a download is running

[d3xter666]

I understand your point, but what botters me is that this might need a bit more of a refactoring.

Here's my rationale.

The AbstractInstaller is an abstract class that implements the lock logic. As the name suggests- it's an installer that is extended by the npm and maven installers.
Cache clanup, except from having in common the locks and paths, is a completelly different topic- it needs to clean the framework files. I have also seen that the framework folder is not configured in the AbstractInstaller, but is hardcoded in every installer.

The only clean option I forsee is to consolidate and reuse the locking logic and abstract the "framework" dir within the AbstractInstaller. Then somehow reuse this information in the cache cleaner.

[d3xter666]

I have refactored the code, so that framework folder is reused accross classes and the locking is respecte.
Hopefully, this change addresses you comment: 8a53eb8

Let me know if you have other concerns on that matter

[matz3]

I think the usability of the command could be improved.

• No information about the actual filesystem paths of the cache and relevant dirs (not in CLI description, not in --help, not in command output
• No information about the relation to ui5DataDir config / UI5_DATA_DIR env var
• No output when command is executed, and it might take a while to calculate the size, so users might assume the command is stuck if it does not print anything for a minute or longer.
• Output lists two different sizes 197.0 MB vs 196.8 MB:

The following items from cache will be removed:
  • buildCache/v0_7 (197.0 MB)

Total: 197.0 MB


✓ Removed buildCache/v0_7 (196.8 MB)

Success: Cleaned 1 entry, freed 196.8 MB

• (minor) Inconsistency in logged paths (framework/ vs framework):

The following items from cache will be removed:
  • framework/ (711.4 MB)

Total: 711.4 MB

Do you want to continue? (y/N) y

✓ Removed framework (711.4 MB)

[d3xter666]

I have tried to improve the situation with the infmration for the execution of the cache clean command and have addressed all your concenrns.

Let me know if there's something more you'd expect.

Regarding the size report, there are some considerations we need to be aware of:

• Getting framework cache dir size might require time. Even if you do that on your machine, it will take time. Even the du command on Mac uses cache in order to be quick, but the first run is not that fast. The optimal solution: Give information about the number of files that will be deleted
• The purge of the DB cache is just the opposite! Selecting COUNT(*) of all rows might take significant amount of time to get the results. On the other hand, the size of the DB can be quite fast.

I have tried to somehow get advantage of these findings and provide the optimal solution- show metrics for what is fast and provide generic messages. Any other solutions will require certain compromises.