Thinking more about how to know what to resolve and what not to means depending on circular reference knowledge. So using an idea from @TristanSpeakEasy, the `*resolver.ResolvingError` now contains a pointer to the original circular error, and it also implements the `Error` interface correctly which allows it simple passage up the chain, without losing fidelity.
Added new documentation example as well
Signed-off-by: Dave Shanley <dave@quobix.com>
A single line that tries to read an HTTP response body and fails is very hard to test without mocking, and the mock does not add value to a single line of code to check for an error that can rarely ever be triggered. Going to settle for 99.9% for now.
Using some designs unearthed from building the higher level model, I have brough that design down to the lower level to speed things up. It only took 8 years, but finally, I think I have mastered mult-threading. No more deadlocks, and no more need for waitgroups for everything.
Building out models that have circular references is tricky. Particularly when they are polymorphic ones. The resolver now searches the polymorphic references for circular references as well (which is returning much more valuable results now). The low level model is now sensitive to this and will avoid building out anything that is circular.
