Treat error classes prefixed with `pkg:::` as internal

[lionel-]

i.e. don't warn testthat users they should test for these classes.

[hadley]

Or should we just back off on the warning all together?

[lionel-]

mmh maybe. We still would like users to test the stable classes instead of the messages though, to minimise breakages when packages are updated with changes to error messages.

Alternatively maybe it should be verify_error(). It would cause a CRAN failure if no error, but only a warning if the error has changed?

[hadley]

I'm now pretty confident that we shouldn't be steering people towards using class because that just eliminates one source of fragility in return for creating another. I like your idea of not verifying the specific error on CRAN, and I'll incorporate that into expect_snapshot_error().

[DavisVaughan]

Unsolicited comment that I like this decision because all of a sudden, with dplyr 1.0.0, yardstick throws these warnings while testing

test-prob-roc_aunu.R:13: warning: AUNU errors on binary case
`roc_aunu(two_class_example, truth, Class1)` generated an S3 error and you are testing the error message.
* The error has class = c("dplyr_error", "rlang_error", "error", "condition")
* Testing with `class` is more robust than testing with `regexp`.
* Do you want `expect_error(..., class = "dplyr_error")`?

I'm not sure how I'd test this in such a way that it works on dplyr < 1.0.0 and doesn't throw these warnings when 1.0.0 is installed (I guess it wouldn't be an issue with CRAN, since they always use the latest package version, but it is sort of annoying when developing)