unloadRecord doesn't always clean up relationships

[DingoEatingFuzz]

Tested in 2.17 and 2.18

Reproduction Repo: https://github.com/DingoEatingFuzz/ed-unload-record-bug
Reproduction Hosted: https://dingoeatingfuzz.github.io/ed-unload-record-bug/

I have the need to remove records from the local store when they no longer come back from server-sent responses. As far as I know, there is no way to do this with ED out of the box, so I have written some special behavior in my application serializer and adapter to do this work.

In my application adapter (unfortunately it has to be the adapter), I am handling the bookkeeping for hasMany relationships. The code looks like this:

https://github.com/DingoEatingFuzz/ed-unload-record-bug/blob/8dcd31f9bb3dce830758485fa92beb58cbca7abf/app/adapters/application.js#L4-L20

This has the intended effect of removing records from the store, but it doesn't update the relationships the unloaded records are members of.

Example:

1. Author hasMany books
2. Publisher hasMany books
3. Loading a publisher's books triggers the above code, removing 0 records, since there are no books in the store.
4. The response includes a book that belongs to Publisher A and Author A
5. Loading Author A's books triggers the above code, removing 1 record, since the book belonging to Publisher A also belongs to Author A.
6. The response includes the same book that was already in the store.
7. The book is re-added to the store.
8. The store now still has one book
9. Author A has one book
10. Publisher A has two books, both with the same ID, one with properties, the other one is a remnant of the unloaded record.

[runspired]

The expected behavior is that unloadRecord marks the inverse side of the relationship as stale, meaning that the next time it is requested it will re-fetch that relationship. It does not clear it from the relationship's internal-state, although it will hide it from the record-arrays and belongs-to relationships given to the UI.

While using unloadRecord in the above way is not a correct design (think of unloadRecod as mark-for-gc-attempt not totally-forget-this-thing-ever-existed), there may still be a bug involved.

I suspect that this might be a manifestation of #5425, I'll have to double-check whether internal-models are removed from the identity-map during an unloadRecord operation.

[runspired]

Also to follow up for casual travelers interested in solving this sort of situation, @DingoEatingFuzz and I had an out-of-band discussion that led to more correct solution: using store.push to push a fresh state for the relationships for the record to be removed into the store (instead of relying on unloadRecord to remove from relationships), at which point unloadRecord truly will cause the record to go away entirely.

[runspired]

Closing in favor of #5425

[runspired]

Reopening because tests confirmed this is a separate issue.