Clean cancel

[kkntl]

I have a suggestion about cleaner error handling, if you like.
(Note that this is my first pull request ever, sorry if I do something wrong)

1. Cancel loading a Page if the parent Document was unmounted.
   I know that react-pdf is not meant to be used like this anyway, but it seems it would be an easy fix.
   (commit "cancel Page load if Document destroyed")
2. Cancel loading a file from the filesystem (FileReader) if the Document is unmounted.
   (commit "abort file load on document reload/unmount")
3. Another test component, to test Page "independant" of Document
   (commit "add test for Page outside Document")

Testing:

1. "cancel Page load if Document destroyed"

• load any PDF file
• check the new checkbox "Page outside of Document"
• click "remove Document" (at the top, in my new test component)
• click "remove Page" (or alternatively: click "next")
• click "re-mount Page"

BEFORE:
TypeError: "this.messageHandler is null"

NOW:
callback .onLoadError("Attempted to load a page, but the document was destroyed")

2. "abort file load on document reload/unmount"

• check the new checkbox "Page outside of Document"
• check the new checkbox "unmount Document on file load"
• load a PDF from a file

BEFORE:
"Warning: Can't perform a React state update on an unmounted component"

NOW:
no error in console (file load was aborted, setState wasn't called)

[wojtekmaj]

Woo, lots of goodness in this PR!

I'm especially curious about the FileReader.abort() thing - didn't know that's possible! I think this deserves to be cherry picked to a separate PR for clarity.

Please allow more time for me to review - extremely busy in personal life recently.

[wojtekmaj]

onLoadError expects Error.

Suggested change

	this.onLoadError('Attempted to load a page, but the document was destroyed');
	this.onLoadError(new Error('Attempted to load a page, but the document was destroyed'));

[kkntl]

changed it

[wojtekmaj]

Not a fan of this formatting inconsistency, but honestly, that should have been linter's job.

[kkntl]

changed it

[wojtekmaj]

I'm wondering, if perhaps making the API consistent with make-cancelable-promise by changing abort to cancel wouldn't be a bettter choice.

[kkntl]

Both ok for me. I am thinking: 'cancel' is something like "I did the request, but I don't want it anymore, don't send what ever you have, no matter if finished or not" (which is what cancelable-promise does). "Abort" on the other hand is "Stop what you are doing right now". But from our perspective I guess what we want indeed is the same in both cases: don't call any callbacks. So 'cancel' would make sense.

[kkntl]

changed it in an extra commit