Update behavior for publisherTrustedAlgorithms field processing

[MBadea17]

At present, for compute type data sets, access verification for the publisherTrustedAlgorithms parameter allows unrestricted access to the dataset for the published algorithms when the array is empty. This approach needs to be revised to align with our new asset verification philosophy, ensuring access is denied unless explicitly defined.

The proposed changes address both issues listed below and consist of the following:

1. Add a wildcard to represent all DIDs. It can look like the following structure:
   {
   "did":"*"
   }

2. Update the node's behavior to perform the following;

• if publisherTrustedAlgorithms array does not exist or is empty, deny access to all algorithms;
• if publisherTrustedAlgorithms array contains an object with "did" === "*", allow access to all algorithms
• if publisherTrustedAlgorithms array contains a list of objects, allow access only to algorithms with "did" and "filesChecksum" in the list.

3. Update the documentation to reflect the changes.

[mariacarmina]

Hello @MBadea17, for now it was not established in the meetings to include serviceId in trusted algo shape. Right now the algorithm can be searched by unique DID, it is a bit unclear described the need to search/filter the access of trusted algorithms by service.
Filtering by service can be meaningful when you handle with multiple fixed rates attached to the algorithm, but not sure if it helps for allowing the algorithm to run on a specific dataset (access control).
I suggest to park the discussion/implementation for this bullet and include only the behaviour for * value for publisherTrustedAlgorithms list in #950.

Thank you!

[MBadea17]

We ran some tests with the publisherTrustedAlgorithms in CLI C2D and found an issue when there are two different services in an algorithm asset, each service referencing the same algorithm file. One service is in the publisherTrustedAlgorithms list, the other is not.

Since the verification for publisherTrustedAlgorithms checks only the asset did and the file checksum of the service, even the service that is not allowed to run on the algorithm will be permitted access to the dataset. To fix this, I think the initial proposal to include in the verification the serviceId should be implemented, even if this requires an update to the algorithm shape.

[MBadea17]

serviceId will be part of the publisherTrustedAlgorithms object. If serviceId exists, it will be validated against DDO services, and if there's a match, access will be granted. Otherwise, access will be rejected.

If serviceId is missing, the validation will continue as currently implemented: did + fileChecksum + containerChecksum.

[mariacarmina]

Linked PRs: #1049, oceanprotocol/ddo.js#31