feat: take all neighbors into account when computing resource digests

[otaviomacedo]

The current definition of the digest of a resource computes a hash of its properties plus the hashes of its dependencies.

But if we have a graph like:

    A --> B
    C --> D

where B and D are identical, the current algorithm will compute the same digest for them, even if A is different from C (and therefore have different digests). This is undesirable, as some cases are considered ambiguous, even if we could very well tell them apart. Real world example:

Role1 and Role2 tend to be identical, but they can nevertheless be told apart because at least the functions will have different properties. So, even if both roles are renamed, for example, we can still provide a valid mapping.

This change improves the algorithm by also taking into account all neighbors of a resource for digest computation. It does this by doing a two pass over the graph: first navigating in topological order and computing the digests, then navigating in the opposite order and doing the same. So each resource has two digests, that are in turn, used to compute the final digest.

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 80.10%. Comparing base (286b063) to head (134b4bf).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #713      +/-   ##
==========================================
+ Coverage   79.38%   80.10%   +0.72%     
==========================================
  Files          49       49              
  Lines        7209     7209              
  Branches      809      817       +8     
==========================================
+ Hits         5723     5775      +52     
+ Misses       1467     1412      -55     
- Partials       19       22       +3     

Flag	Coverage Δ
suite.unit	80.10% <ø> (+0.72%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[rix0rrr]

where B and D are identical, the current algorithm will compute the same digest for them, even if A is different from B (and therefore have different digests).

Typo? A is different from C ?

---

So we now have two digests. Let's give them names (not the best ones, maybe you can come up with better ones).

• downdigest - the digest of a resource's properties and all of the resources it references.
• updigest - the digest of a resource's properties and all of the resources referencing it.

If we always use both digests to come up with the mapping digest (mappingdigest = digest(down + up)) we are sensitive to incoming references changing. Does that ever pose a problem?

Or would we be better off having a 2-step digest, where we map using the downdigest first, and then only involve the updigest if there is a collission?