Allow conan cache path adoptions via conf core.cache:path_prefix_fmt

[thorsten-klein]

Allow users to change the conan cache path to a more human-readable one.
Therefore a new conan conf core.cache:path_prefix_fmt is introduced which allows users to specify a format string for the path prefix for the cache folder. The prefix defaults to ref.name[:5] (which is currently the default).
The format string can resolve the RecipeReference ref, for example '{ref.name}{ref.name}{ref.revision}_'

This is just a first draft with minimum effort to showcase the proposal.
If you agree with this proposal in general, I will continue to create specific tests for this feature.
Maybe I need your help with the tests: How can I enable this conf for all available tests to make sure that it does not break anything?

---

Changelog: (Feature): Allow conan cache path adoptions
Docs: https://github.com/conan-io/docs/pull/XXXX

• Refer to the issue that supports this Pull Request.
• If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
• I've read the Contributing guide.
• I've followed the PEP8 style guides for Python code.
• I've opened another PR in the Conan docs repo to the develop branch, documenting this one.

[memsharded]

Hi @thorsten-klein

Thanks for your contribution.

Extending the cache path, making it longer that it already is, can be problematic.
We did a good effort to estimate the shortest path required to guarantee entropy and avoid collisions, while keeping the shortest possible path. This is important for several reasons, including that long paths can overflow different tools in different situations. For example, it is notorious the case of Windows with the filesystem path limitations that nowadays it is still limited in many cases to 260 characters. While that can be configured to allow longer paths, there are still some tools that might fail because of long paths.
But more problematic in Windows, and still without a solution is the problem with cmd line length and environment variables length, that will overflow very easily in different scenarios if paths become longer.

Changing the conf to a different expression will also break existing caches, in a relatively bad way. So users that start to use it or users that decide to change the expression will find painful and annoying situations with their caches broken and needing a complete reset.

Furthermore, based on our experience with Conan 1, having recognizable folder names like mypkg/myversion/... in the Conan cache will make more users to leverage that for some automations, abusing an internal implementation detail instead of the provided tools and APIs to access the storage and functionality.

These cases will also inevitable lead to users reporting to us, sometimes annoyed because this kind of issues could sometimes be not clear and difficult to understand and debug, and it will require us to support them, explain things, and deal with it.

While we understand the advantages of having cache folders that are more human readable, we considered the pros and cons in Conan 2 and decided to implement the current solution.
We did a large effort to provide better and detailed logging (the terminal output is much cleaner, structured and detailed), and tools like conan cache path to avoid the need to manually navigate the cache folders, which would be the use case that is mostly affected by the current Conan 2 approach.
We are very heavy Conan users, obviously, and we have seen already many hundreds of Conan users using Conan 2 and this sounds a reasonable trade-off, nowadays with Conan 2 it seems that manually navigating the Conan cache by folders is no longer a relevant use case.

In any case, I am adding a look-into label to discuss the possibility with the team, we are as always open to reconsider things. It would be good to have more visibility and details about what problem or pain is this solving, and how it would be leveraged if it would be merged. Thanks!