The linkName in the @link decorator doesn't assign the value on the correct property

[alexandrevryghem]

Describe the bug
When you have an @link with a linkName that differs from the property to which you added the decorator, the embedded data will not be linked to that property, but instead, it will be linked to a new property with the name defined in linkName.

To Reproduce
Steps to reproduce the behavior:

1. In the item.model.ts class, rename the accessStatus property to, for example accessStatusValue, and update the @link to @link(ACCESS_STATUS, false, 'accessStatus').
2. Fix the usages of accessStatus in AccessStatusBadgeComponent, add accessStatus to the list of BROWSE_LINKS_TO_FOLLOW, and add a pipe with a take and a console.log to log the page of items in BrowseService#getBrowseItemsFor.
3. Now go to the /browse/dateissued page and check your console. You will see that the value is not set on the accessStatusValue property, but on accessStatus.

Expected behavior
The embedded data should be saved on the property to which you added the @link decorator.

Related work
I discovered this bug during #2480. After implementing this fix, it will be important to check that these changes still work as expected. The current implementation now only checks if the property with the linkName has a value, but when this is fixed, this should be updated. Otherwise, some followLinks will never be automatically invalidated when their parent is invalidated.

[pcg-kk]

@alexandrevryghem I'm unable to replicate the issue you're experiencing, or perhaps I'm misunderstanding your point. When I utilize the following code:

   @link(ACCESS_STATUS, false, 'accessStatus')
     accessStatusValue?: Observable<RemoteData<AccessStatusObject>>;

The accessStatusValue in my item correctly receives an assigned Observable:

Could you please provide more details or guide me to where I should be looking to reproduce the issue?

[alexandrevryghem]

@pcg-kk: I created bb13004 with proof of how it doesn't work with some logs. This time I tried renaming the thumbnail property to thumbnailBitstream and I am still able to reproduce the error, and the thumbnails also don't render anymore because of this. This isn't really a big bug because now all the properties probably have the same name as the linkName otherwise they don't work/are not used. I only opened this ticket in order to remember that these changes need to be adapted when this eventually gets fixed, I'm also not sure we really have to allow this customisation since I don't really see the benefit in it.