Migrate api/core and types Modules to Separate Repositories

[c-kruse]

The sensu-go repository currently includes several go modules in addition to the application, github.com/sensu/sensu-go: the core api modules github.com/sensu/sensu-go/api/core/v2 and github.com/sensu/sensu-go/api/core/v3, and the types module github.com/sensu/sensu-go/types. The inclusion of these additional modules in the sensu-go repository has become especially burdensome since the introduction of a Latest and LTS version of the sensu-go product.

Feature Suggestion

We should migrate the core api and types packages to their own repositories to allow for a cleaner development workflow and avoid further confusion around the versioning of these packages.

Packages that depend on these modules can either use a go.mod replace directive or update all of their imports to reflect the new module names.

• migrate modules to new homes
• publish releases
• remove api and types directories from sensu-go and include 🌵 noisy README notice of migration 🌵

Possible Implementation

github.com/sensu/sensu-go/api/core/v2 and github.com/sensu/sensu-go/api/core/v3 are to be combined into a github.com/sensu/core module with v2 and v3 releases. Development will be merged to a main branch, and tags will be published for v2 and v3 releases continuing on the track that they were last published from the sensu-go repository. Example: v2.15.0 will be the final release of github.com/sensu/sensu-go/api/core/v2 and github.com/sensu/core v2.16.0 will be made available as the first v2 release of the core api.

github.com/sensu/sensu-go/types will be migrated to github.com/sensu/types. v0.11.0 will be the final release of the sensu-go/types module and the first version of github.com/sensu/types will be released as v1.0.0.

We should consider greatly reducing the scope of the types package on migration and release of the 1.0 version. Potentially moving all compatibility and wrapper shims to sensu-go, and only preserving a resource registry and resolver with no circular dependency on core/v3 and core/v2.

Context

We have been running into all sorts of pain points when developing changes to the types and api modules for the 6.x track. I believe separating modules into their own repos will make development and release management more intuitive.

[c-kruse]

Currently this is held up pending the 6.8.2 release.

The 6.8.0 and 6.8.1 releases have targeted a diverging version of the api/core/v3 module. This diversion needs corrected before we can migrate these modules to new locations.

[c-kruse]

Migration strategy doc: https://docs.google.com/document/d/1WkxACxR7e769a7IkdJW9FLO0cBik7azVENVLRUgU9Lg/edit?usp=sharing

[fguimond]

Moved to 6.10.0 to allow getting our feet wet with the changes early in the release cycle.