Increase priority of libraries mentioned explicitly as dependencies

[alranel]

Describe the request

This proposal includes two distinct changes:

1. When resolving dependencies for a library, give higher location priority to libraries mentioned explicitly in the depends= field of library.properties file
2. When resolving dependencies for a sketch, give higher location priority to libraries mentioned explicitly in the libraries field of sketch.yaml file

Such changes are independent one from each other. At the moment, the first one would be more useful than the second one.

Describe the current behavior

As of now, the dependency resolution algorithm does not take into account whether a candidate library was specified as an explicit dependency for the current library/sketch.

This has the following effects:

1. In the Arduino Web Editor, the library selection algorithm always runs against the entire catalog of libraries as users can't control what libraries are installed or not. This has the effect that when including a header file, there's no way for users to make sure that it gets taken from a specific library, because selection is probabilistic. The only case when selection is deterministic is when including a header file matching the name of the desired library, as this will always get the highest priority and there's no chance another library will shadow it. Here's an example of a legit library that unfortunately can't be used because other libraries provide a header file with the same name but have higher priority.
2. The probabilistic selection of libraries comes with a priority squatting security risk in case someone publishes a new library which gets higher priority. Users recompiling existing sketches would not notice this and could be subject to a supply chain attack.

Arduino CLI version

0.34.2

Operating system

N/A

Operating system version

Any

Additional context

Some further considerations:

Retrocompatibility. Changing the prioritization rules may of course be a breaking change for users relying on the current set of rules as a different library may be picked up. These scenarios would be affected:

• A library relies on a header file provided by another library not mentioned in itsdepends= AND such header file name does not match the library name AND another library mentioned in depends= provides a header file with same name which would then take priority. This scenario appears very unlikely and shall be addressed by fixing the affected libraries, if any.
• A library includes a header file provided by multiple libraries mentioned in its depends= AND the header file name doesn't match any of the names of those libraries AND the intended library is the one selected by the current probabilistic algorithm. This scenario appears marginal since it's slightly randomic, but still possible.
• A sketch relies on a header file provided by a library whose name does not match the header file name AND it has a sketch.yaml file mentioning another library providing a header file with the same name which would then take priority. This situation appears very unlikely as sketch.yaml files are not popular yet and they are usually generated automatically so there's no reason only some libraries would be mentioned.

Security. This proposal increases the security level of the library selection algorithm by reducing the risk of supply chain attacks exploiting priority squatting. It also increases the build reproducibility level by letting users pin the library to be used for a given include.

Issue checklist

• I searched for previous requests in the issue tracker
• I verified the feature was still missing when using the nightly build
• My request contains all necessary details