feat: Add strict (RFC-9562-compliant) parsing and validation functions

[jonathansharman]

#37 added parsing support for non-RFC-9562-compliant UUIDs of the form {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} or xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx. (Actually, the curly braces are allowed to be any byte, which is even more permissive - see also #60.)

We at nicheinc would like to be able to opt out of this more lenient parsing, to ensure that a successfully parsed UUID is compliant with RFC 9562. Concretely, the uuid's default lax parsing has caused issues for us during fuzz testing, leading to us writing our own stricter parseUUID function wrapping uuid.Parse. However, it would be nice if strict parsing were available out of the box.

To that end, this PR adds a corresponding "strict" version for each parsing function:

Existing function	Strict function
Parse	StrictParse
ParseBytes	StrictParseBytes
MustParse	MustStrictParse
Validate	StrictValidate

Strict is the first prefix I thought of, but there may be a clearer name - happy to change it if so.

Note that I've chosen to implement the existing lenient functions in terms of the new strict functions. They could instead be kept totally independent, at the cost of code duplication.

Alternative Solutions

1. Instead of separate functions, the existing functions could take a variadic options parameter, and there could be a "strict" option to opt out of lenient parsing. I didn't go with this because it's more verbose and (barring aggressive compiler optimization) less performant.
2. In my opinion it would have been preferable for Add new parsing support #37 to have added separate functions for lenient parsing, rather than changing Parse. Another option here is to create a new major version of uuid, where Parse, etc. are strict by default, with lenient parsing being moved to new functions. However, I don't think that's worth a whole new major version by itself. It could be worth considering for uuid/v2, if one were ever planned.

Strict Unmarshaling

This PR does not provide strict versions of the UnmarshalText and UnmarshalBinary methods in marshal.go since their purpose is to implement the encoding.TextUnmarshaler and encoding.BinaryUnmarshaler interfaces, and a type can only have one implementation of an interface. 😕

The only two approaches I can think of to enable strict unmarshaling are:

1. Add a package-scope variable to uuid that toggles the behavior of UnmarshalText and UnmarshalBinary. This kind of invisible, package-wide configuration is in my opinion an antipattern and not worth pursuing.
2. Add a wrapper type around uuid.UUID that has strict UnmarshalText and UnmarshalBinary methods. This option is pretty noisy and unergonomic.

I'd love to hear if anyone can think of a more reasonable approach. Regardless, I think it would be beneficial for uuid to provide standard-compliant parsing functions even if it can't include unmarshaling.

Edit (2025-07-18): Using encoding/json/v2, it's possible to pass *json.Unmarshalers to json.Unmarshal to override unmarshaling behavior for particular types. As an extension of this PR, it should be possible for uuid to provide a *json.Unmarshalers that enforces strict parsing, corresponding to StrictParse. That seems to me like the most ergonomic way to support strict unmarshaling in a backward-compatible way.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.