Support RDS snapshot configurations in spec

[nabuskey]

Is your feature request related to a problem?

In today's community meeting, we had a discussion around the new final snapshot configuration option in the RDS controller. This was introduced in this PR as requested in this issue. This is a great addition to the RDS controller since final snapshot operations are commonly used.

We had discussions around using annotations vs spec. I am documenting them below.

• Spec field is the reflection of state of the resource. Operations around resources do not fit in spec well.
• Forward compatibility and cost of renaming fields. There are issues around re-naming fields and introduction of new fields for GA controllers must be considered carefully.
• Using annotations is a good starting point for supporting this feature. We can use the same logic for spec field, if desired.
• Annotations are hard to document. Currently they are documented manually in each repository and not automatically generated aside from go doc.
• There are no mechanisms in ACK to generate code or docs for annotations.
• While the number of current annotations are small, what should we do when the number grows? Do we need generation tools for annotations as well?
• The operations around snapshots are very common when using RDS. If the purpose of the RDS controller is to manage the lifecycle, snapshot operations should be part of spec.
• When enabling self service for developers, descriptions in spec is easier to reason about because there are tools that can parse OpenAPI spec.

Describe the solution you'd like

I think the move to use annotation was right as the first implementation to support snapshotting features because it allows for experimentation and identify any bugs. As the usages of the annotations grows , I think they should be moved to spec. When I am using RDS controllers, I want to manage the lifecycle of RDS instances. IMO this includes snapshots.

Describe alternatives you've considered
N/A