#302: do not use ReferenceSchema#referredSchema for equals+hashCode

[tmarsteel]

This solves Issue #302. Not including the referred schema feels right to me since it depends on the schemaLoader. I have no idea whether people rely on referredSchema being in equals+hashCode, though.

[coveralls]

Coverage decreased (-0.04%) to 91.532% when pulling 631d08d on rebuy-de:cyclic-schema into fd33c26 on everit-org:master.

[erosb]

Hello @tmarsteel , do you think we loose anything if we keep this line? So my concern is that, with this change, there can be (rare) cases when two schemas are considered equal when they are not (I mean eg. two references pointing to # , but this denotes the roots of two different schema documents).
What do you think about keeping this line? I see that it might run into infinite equals() recursions, but that's probably a very rare case.

[rayokota]

In the case of Confluent Schema Registry, we call equals quite often on schema. So we would prefer the fix above.

[tmarsteel]

That's a very good point. The testcase and my actual cyclic schemas both work with referredSchema being included in equals.

[tmarsteel]

Hm, this doesn't suffice yet. The HashCodeRecursionTest succeeds in my IDE but fails in maven. Looking into it.

[tmarsteel]

Okay, so it turns out that equals will always cause a stackoverflow when you call it on equal (but not identical) schemas. I have such a cycle in one of my projects, so keeping referredSchema in equals doesn't work for me. I see two solutions for me here :D

1. modify my own code to assure any schema file is not loaded more than once so the equals method can take the identity-shortcut
2. Since ReferenceSchema is the only way to create cycles in json schemas, these cycles can be detected and handled there. I have drafted something (13438c9) that passes the tests, but i'm very unsure whether this code should go productive anywhere

[rayokota]

@tmarsteel @erosb We would prefer the fix where referredSchema is excluded from both equals and hashCode.

If a client wants to additionally compare the referredSchema, the client can always do that check "manually". Optionally perhaps a deepEquals method can be provided that does that. However, without this PR, there is no way to avoid the StackOverFlowError.

In other words, we need one method to avoid the StackOverFlowError. Optionally, you can provide a separate method deepEquals, which might still result in the error.

[tmarsteel]

@rayokota that sounds very reasonable to me. I'm okay with implementing it. It would be a breaking change, so likely the release will not be that soon, will it? @erosb