Will add a golang concurrent test (for -race coverage) today, basically matching the style of that in my other PR.

FYI @sunsingerus : I plan on making my way through each of registry/status/announcer, but thought having a separate PR for each would be valuable in keeping discussion focused (and not missing details due to the size of one big PR)

Update: I'm marking this as a draft for now, will promote back to PR when I have landed the concurrency test coverage and continue plumbing through synchronization into all getter/setter accesses to the status (I'm currently working my way through the medium sized surface area exposed by the combination of EnsureStatus()... calls and the slightly messier to track direct ChiStatus struct field accesses.

I'm pondering a few routes forward:

• Exposing a general purpose readStatus(func(s *ChiStatus){}) and updateStatus(func (s *ChiStatus){}) call that transparently performs necessary locking – something error prone but less error prone than throwing locks on existing field level accesses
• Chase down all existing field-level accesses of ChiStatus struct fields (exported for serialization purposes) and add explicit synchronization in all the places I find – something error prone and probably inviting future regressions
• Introducing a new type that wraps ChiStatus and guards all read/write/merging/etc, pushing down ChiStatus to only serialization/deserialization to/from JSON/YAML – probably the least error prone technique since I'll be able to create a little more friction against direct field level accesses that bypass synchronization

Yeah, this is going to be more of a lift than I first thought, so I'm going to close this PR for now and reopen it when the branch is further along. Sorry for the premature draft :)

Whoops, can't reopen this because I rebased/squash after taking a second approach. Will open a new PR. Sorry!