V8 recovery from bad javascript

[dpezely]

After an adventure through the wilderness of V8 things... (stories for another time), there are zero changes to erlang_v8 that would be required for this. (However, there are additional tests in a PR there demonstrating the V8 behavior.)

Instead, the idea is for router handling the entire burden of ambiguous V8 errors and recovering from them by restarting the V8 VM.

From where this branch was made, merging this would also restore Pierre's feature of backoff & retry. (That set of features was partially reverted and augmented by @michaeldjeffrey's merge of commit, 6852b94fa, which could be cleanly reversed if we decide to go that direction.)

QUESTION: how to proceed with the merge? It's probably best to essentially rebase this branch to current HEAD on master, but do we stick with current retry logic, or reinsert use of the backoff library?

Heart of the matter at hand:

V8 errors as available via erlang_v8 offers insufficient granularity. Fixing that requires reaching beyond the C++ Erlang Port to resolve. However, V8 docs don't easily accommodate cherry-picking one's way through for our purposes here.

OPERATIONAL NOTE:

Track repeat offenders of bad JS code via external monitoring.

Look for log entry with this RegEx pattern:

^V8 call error="([^"]{1,10})" uuid=(\S+) app_eui=(\S+) dev_eui=(\S+)$

[dpezely]

Superseded by PR #528