Additional CRDs for RabbitMQ K8s API

[st3v]

Is your feature request related to a problem? Please describe.
This issue aims to track our thinking and any resulting work in terms adding lower-level CRDs that represent RabbitMQ primitives (e.g. vhost, user, queue), as well as higher-level abstractions that build on top of those primitives in conjunction with the pre-existing rabbitmqcluster CRD.

Describe the solution you'd like
Create a proposal that documents the different CRDs and their relationship with each other. Discuss alternatives for how to progress with the implementation of those CRDs (i.e. start bottom-up or go a different route).

Describe alternatives you've considered
See upcoming proposal that will be created as part of this issue.

Additional context
Pre-exiting work: https://miro.com/app/board/o9J_kvHmivs=/

[github-actions]

This issue has been marked as stale due to 90 days of inactivity. Stale issues will be closed after a further 30 days of inactivity; please remove the stale label in order to prevent this occurring.

[github-actions]

This issue has been marked as stale due to 60 days of inactivity. Stale issues will be closed after a further 30 days of inactivity; please remove the stale label in order to prevent this occurring.

[ChunyiLyu]

@mkuratczyk add context about what's necessary features to support knative

[mkuratczyk]

Dear folks, who are subscribed to this issue: we want to start working on this but have some questions about how this should work. It would be very helpful to talk to you so please reach out on rabbitmq.slack.com or here. Let's make sure what we build is actually useful for you. :)

Questions such as:

• source of truth - what would you expect in certain scenarios when Kubernetes resources don't match the actual state in RabbitMQ
• security - how do you expect to verify that someone who created, for example, a Queue resource in Kubernetes (with a reference to a RabbitMQ Cluster), is actually authorized to create queues in that cluster

Thanks!