Enso Atoms should expose structural equality through the Polyglot boundary

[wdanilo]

This task is automatically imported from the old Task Issue Board and it was originally created by Radosław Waśko.
Original issue is here.

---

Team

Technical Designer: ...
Implementer: ...
Acceptance/QA: ...

Why

As a library developer
I want Enso Atoms exposing structural equality when accessed from polyglot (Java) code
So that I can use Java utilities like HashSet with Enso Atoms and get expectable results

Acceptance Criteria

Scenario: 
GIVEN two structurally equal Enso Atoms
WHEN they are passed through a Polyglot boundary and the Java `.equals` function is called to compare them
THEN it should return `true` as expected; moreover the exposed `hashCode` implementation should also be consistent with the `equals` method (as described in `Object` javadoc - o1.equals(o2) must imply that `o1.hashCode() == o2.hashCode()`)

Additional Notes

Once this is implemented, the pending test relying on this behaviour should be re-enabled.
The relevant test is should correctly handle distinct with custom types like Atoms located in test/Tests/src/Data/Vector_Spec.enso.

Comments:

A scenario to test this can be:

from Standard.Base import all

polyglot java import org.enso.bugrepro.helpers.App

main =
    p1 = Pair 1 2
    p2 = Pair 1 2

    IO.println "Enso ==: "+(p1 == p2).to_text
    IO.println "Java equals: "+(App.checkEquality p1 p2).to_text

    IO.println "Hash codes: "+(App.getHashCode p1).to_text+", "+(App.getHashCode p2).to_text

with the following Java file packaged into a JAR and put into /polyglot/java/ directory inside of the Enso project:

package org.enso.bugrepro.helpers;

public class App
{
    public static long getHashCode(Object o) {
        return o.hashCode();
    }

    public static boolean checkEquality(Object o1, Object o2) {
        return o1.equals(o2);
    }
}
``` (Radosław Waśko - Jan 17, 2022)
<hr />
This is very related to the Hashset work. (James Dunkerley - Feb 3, 2023)
<hr />
The test in `Vector_Spec.enso` you are mentioning is already fixed on my local branch in https://github.com/enso-org/enso/pull/4067/commits/548920b20a5f44d3951171c999a0f0e2c3f9adc0#diff-6a51a720e46f1443fc109ddce7fbcebfb231b4a7b9616aae879e9b8bfe1fe7e2 by introduction of the Comparator API. Moreover, #184074597 seems related (Pavel Marek - Feb 3, 2023)
<hr />

[jdunkerley]

If this comes out of the work on HashMap and equality would be a nice to have.

[Akirathan]

If this comes out of the work on HashMap and equality would be a nice to have.

This won't be part of #4067. It is related to #5259 and needs further discussion, because there is no simple solution for this.