Consider aligning 3.3 release with 8.16 stack release

[jsoriano]

There are some new features that are currently merged in the spec that need changes in Kibana. They are currently in development and could be potentially shipped in stack release 8.16. If that's the case, we should release a 3.3 spec including the features that are finally released, and bump the spec.max constraint in Kibana before the freeze.
This may imply to reorganize the changes we were planning for 3.3 and 3.4.

The features are:

• Knowledge bases, originally planned for spec 3.4, but could be moved to 3.3 ([KB] add KB support to fleet package spec and implementation kibana#193849) cc @pgayvallet.
  • Reverting the change in Revert "Add support for Kibana knowledge base entry assets (#807)" #813.
• Content packages, originally planned for spec 3.4, but knowledge bases depend on this. We could release content packages with knowledge bases in 3.3, and let other features for 3.4. cc @elastic/ecosystem. Implemented in [Fleet] Support content packages in integrations UI kibana#192484.
• SLOs, planned for 3.3. Pending PR in [SLOs][Fleet] Install integration SLO assets kibana#186974. cc @mgiota

We could reorganize the changes so the ones included in 8.16 are included in spec 3.3, and the changes not released in 8.16 are moved to spec 3.4.

[jsoriano]

We are releasing by now a 3.2.3 version, needed for agentless. Knowledge bases are reverted. Rest of changes mentioned in the description stay by now on 3.3 and 3.4.

[jsoriano]

We have released a 3.3.0 version so kubernetes_otel package can be used in 8.16.0. Related changes:

• Prepare release 3.3.0 #818
• Chore(deps): bump github.com/elastic/package-spec/v3 from 3.2.3 to 3.3.0 elastic-package#2166
• Change format_spec in the kubernetes_otel package to 3.3.0 integrations#11435
• Update max supported package version kibana#196551

SLO changes have been moved to 3.4.0.

Closing this as we have released 3.3 at the end for 8.16.0.