Add a basic fuzzer - FuzzScopedHTML

[jasikpark]

Changes

Small bugfixes that will be eventually moved to other PRs

Testing

This PR is tracking the addition of a simple go based fuzzer to test the html parser / scoped styles generator.

I'll add fixes to bugs I discover as I go along, and then eventually I'll break out the bugs and this fuzzer into individually mergable PRs

This can be run via go test ./internal/transform -fuzz=FuzzScopeHTML from the root directory to run an ongoing fuzz test of the html scoping.

Uses https://tip.golang.org/doc/tutorial/fuzz

Docs

There should be contributor docs for how the fuzzer works, how to run it && how to update fuzz tests

[changeset-bot]

⚠️ No Changeset found

Latest commit: 15dd962

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[jasikpark]

another option that isn't blocked on updating to go 1.18 would be using fast-check: https://github.com/dubzzz/fast-check/tree/main/packages/fast-check/documentation

this allows for creating property tests to augment unit tests by generating data of a certain shape and asserting certain properties of it, like that a parse should contain only unicode strings or an error.

ex: https://github.com/dubzzz/fast-check/blob/main/examples/001-simple/fibonacci/main.spec.ts

ex closer to the compiler: https://github.com/dubzzz/fast-check/blob/main/examples/001-simple/indexOf/main.spec.ts

[jasikpark]

This is ready for review now that go is > 1.18!

This can be run in CI with something like https://github.com/jidicula/go-fuzz-action or something similar, or often able to be run in person.

I'd say merge && run in person for now - though eventually hopefully all immediate bugs are found that would make this fail outright

I'd probably recc https://google.github.io/oss-fuzz/getting-started/continuous-integration/ actually, since they have the most experience running fuzzing continuously in CI. Though this would be a more of "catch bugs in recently commited code" setup