Cyclic references resolve

[m1c1b]

• [x] You have read the Spring Data contribution guidelines.
• [x] You use the code formatters provided here and have them applied to your changes. Don’t submit any formatting related changes.
• [x] You submit test cases (unit or integration tests) that back your changes.
• [x] You added yourself as author in the headers of the classes you touched. Amend the date range in the Apache license header if needed. For new types, add the license header (copy from another file and set the current year only).

---

Hello! First of all I want to describe the problem that I have fixed.

Imagine a couple of @RedisHash entities that references one to anoter like A <->B. In that case StackOverflow will be thrown because of infinite calls stack for resolving @Reference fields on any kind of reading.

So I have made a clone of MappingRedisConverter with name ReferenceMappingRedisConverter but with one difference. ReferenceMappingRedisConverter has context of already resolved field branches, ReferenceRedisAdapter control the context of converter on reading operations.

I'm not really confident should I edit already existing classes or create new, this is why I have created new ones. I didn't know what version should I write in @since javadoc annotation, so I just didn't write it.

And of course I am ready to write documentation for my code and a sample configuration in spring boot, but I need a little bit explanation of how to do it.

[mp911de]

Thanks for your pull request and sorry for the long silence. It makes indeed sense to have cyclic guards in place. With the current state, it is impossible to review the changes because the converter is fully duplicated. Instead, it would make sense to carry around a contextual state object that holds references to resolved objects from hashes and have that as starting point.