Extends #603 to fix related errors

[dgeb]

This PR is based on #603 and extends the fix for SyncRecordCache to apply to AsyncRecordCache as well.

Furthermore, a related set of bugs is resolved, in which findRelatedRecord and findRelatedRecords should throw a RecordNotFoundException when the primary record can not be found in a cache. This makes them consistent with findRecord.

Closes #603

[henrixapp]

Furthermore, a related set of bugs is resolved, in which findRelatedRecord and findRelatedRecords should throw a RecordNotFoundException when the primary record can not be found in a cache. This makes them consistent with findRecord.

Does that mean, that I have to be sure that the findRecord has succeeded? I'm currently using an optimistic pattern to query relationship...

[dgeb]

@henrixapp This change allows you to distinguish between cases when a primary record is completely missing vs. when a relationship to that record is just empty.

If you issue a query such as store.query(q => q.findRelatedRecord({type: 'planet', id: 'jupiter'}, 'moon'), an error will be thrown if the planet jupiter does not exist in the store. This is consistent with issuing the same query against a JSONAPISource when the planet jupiter doesn't exist on the server (the 404 error will be thrown). It's also consistent with the behavior of findRecord for all sources.

If you want to adjust the contents of a cache prior to the query being processed, you could do so in a beforeQuery strategy.

Another approach entirely would be to inspect the contents of the cache via store.cache.getRelatedRecordSync() to see what's in memory. See these record accessor methods. This would be appropriate if you just want to just check what's in the store (and its cache) rather than issuing a query that can be coordinated with other sources.

If neither approach works for you, please expand upon your use case here or in gitter so I can better understand.