expose internal test tools

[amoore877]

Specifically referencing v2/internal/test, though there may be other instances.

Use case:
In trying to test an in-house health checker against WorkloadAPI/FetchX509SVID components, go-spiffe code tends to expect very precise data (key usage, parseable cert/key/bundle DERs...) and a lot of convenience code exists for testing but is blocked off inside of internal.
It would be helpful to expose this tooling for operators:

• out of convenience
• automatically keep operator's tests and go-spiffe imports in-sync, as testing libs must inherently be kept up to date with breaking changes in go-spiffe

[zmt]

I think the fakes, etc. probably need some work to be ready to graduate from internal. At least that was the case a few months ago when I was last reading through the code there. Perhaps we can identify a laundry list of specific issues that will require code changes to make the testing utilities ready for export and use this issue to track?

[azdagron]

I think providing a convenient fake implementation of the Workload API is certainly within the purview of go-spiffe. I don't think the internal test infrastructure is quite there. They were not authored for public consumption, but rather to facilitate testing the internals of the library, and the consequences of that show up in some of the design decisions. We made them internal precisely because we didn't have the time to go through the exercise of determining what would make a useful fake that would be subject to compatibility guarantees.

If go-spiffe is going to export a convenient fake implementation, I think @zmt is right, we need to identify some good initial use cases and design the fake in a way that makes it extendible in the future in code compatible ways.