Description of problem:
using geo-replication with deep directory and lots of hardlinks can lead to "too many levels of symbolic links" error when files should be removed on the slave

Version-Release number of selected component (if applicable):
all of 4.1, but also in 3.12


How reproducible:
needs special directory, in our case trees of node modules or ruby gems 

Steps to Reproduce:
1. use rsnapshot to create backups of a virtual machine on the master
2. rsnapshot creates hardlinked copy of the synced tree to daily.0 which then get rotated
3. so .sync → daily.0, mv daily.0 daily.1 & .sync → daily.0
4. at end of rotation daily.6 is renamed to _delete.someid and gets removed.

Actual results:
the geo-replication of that deletion triggers the "too many levels of symbolic links" error, but after repeated attempts then finally manages to delete the hierarchy nevertheless, but geo-replication is forced back to history crawl and the process takes way too long.

Expected results:
no problems in removing files that it managed to create without problem earlier.

Additional info:
ruby gems and node collections are likely to trigger it, but need to be largish, but by no means excessive

one example:
# find /master_mnt/path/to/site/bundle/ruby/2.1.0/gems/ -type f |wc -l
4972
# find /master_mnt/path/to/site/bundle/ruby/2.1.0/gems/ -type d |wc -l
918

the contents don't change frequently, so most of the files are hardlinks with 8 to 12 targets (.sync, daily.0 to daily.6, weekly.0 to weekly.3, _delete)