Handle 304 (and others?) better in the node documentLoader

[marcvanandel]

If a context that has to be resolved returns a HTTP 304 the node documentLoader does not resolve properly. It seems that all HTTP 300 - 399 codes are handled like redirects ... which they are not.

More precisely in this comments at lib/documentLoaders/node.js:127 where a 304 is handled similarly as a 302 ... but a 304 means 'not modified on the server side' (see mozilla http 304 documentation).

This can be reproduced by altering the node-document-loader-tests.js:83 and add .status(304) to the response:

_app.get('/data/:id', _store, (req, res) => {
  res.status(304).json(_data[req.params.id].content);
});

I stumbled upon this bug (feature?) with loading the json-ld context of the ed25519-signature-2020 because this returns a 304 (200 first time but 304 all other times; it also contains a redirect first)

[dlongley]

We should simplify the node document loader to not use the manual redirect flag anymore. It was written a long time ago -- and now relies on fetch, and the fetch implementation (as of who knows when) now properly follows the fetch spec and returns an opaque response when manual is used. We needed to use manual flag in the past to check for cycles and to get the final redirection URL to return as documentUrl.

From what I've read, we can rely on fetch to handle cycles and too many redirects and it returns the final url in the response as the .url property. We should be able to now remove the manual flag as well as any old commented caching code and special redirect handling code. We will still need to handle the link header -- because that's JSON-LD specific, but we should not need special HTTP 3xx handling code anymore.

I'll also note that the context recursion error we have in the node loader is not a proper error (that's handled elsewhere) for a number of reasons ... and the above changes would eliminate the need for it anyway.