fix: Test for invalid byte array sizes and ranges in v1(), v4(), and v7()

[gaoyia]

Check and throw the following conditions for v1(), v4(), and v7():

• options.random or options.rng() returning too-short byte arrays
• range errors involving buf and offset

[gaoyia]

maybe we shoud

• use random value
• throw an Error
• pad with zeros： uuidv4(v4options); // ⇨ '109156be-c4fb-41ea-b1b4-efe1671c0000'

[broofa]

Sorry, I missed your last comment. I've updated the PR as follows:

• throw if options.random or options.rng() return insufficient entropy (too-short array)
• throw if byte indexes over/underflow buffer range
• Apply changes to v1() and v7() as well

Note: I removed your code that silently switched to rng() if the user-supplied options.random or options.rng() produced a too-short array. My rationale for that is if a user is explicitly providing one of those options, then they would be surprised to find the internal rng() being used. Better to be explicit about the problem rather than make assumptions about the solution.

[broofa]

@ctavan : Okay to push this out as a patch release? I only hesitate because this code may throw where it didn't previously. While that's not strictly a breaking API change, there's a chance it might catch some users unawares. (But those users would see obviously corrupted UUIDs currently, so it's a bit of a self-correcting problem.)

It's a little surprising this hasn't come up previously. I do vaguely remember encountering this in development years ago and thinking that "undefined" appearing in a UUID string would throw for other reasons, so wasn't a concern. But that may have been before buf support was fleshed out? Or before the v8 or v10 refactors? I forget.