Checklist:

• Have you added an explanation of what your changes do and why you'd like them to be included?
• Have you updated or added documentation for the change, as applicable?
• Have you tested your changes on all related environments with successful results, as applicable?

Type of Changes:

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

What is the current behavior? (link to any open issues here)

What is the new behavior (if this is a feature change)?
I think this is a really nice one. The idea is to automatically tune postgresql parameters according to https://pgtune.leopard.in.ua/#/ which I've found very useful over the years.
This is quite simple as Patroni dynamic configuration is already implemented.

The PostgresCluster type now has a new field: AutoPGTune, which has two fields: AppType and HDType, all optional.
If AutoPGTune is set, postgresql parameters are tweaked using the memory and cpu requests, and AppType and HDType if defined. None of them are mandatory, related parameters will simply not be tweaked, and AppType is assumed mixed if no value is given.
Obviously this is optional and not mandatory, not set by default.
AutoPGTune uses Patroni DynamicConfiguration, so enabling this essentialy enables Patroni. I've thought about putting the AutoPGTune field under Patroni but it seems confusing as they're not directly related. I'll leave it for you to decide though.
Enabling/disabling AutoPGTune does not cause a restart.
If both AutoPGTune and Patroni.DynamicConfiguration are set, Patroni.DynamicConfiguration overrides AutoPGTune, e.g.
autoPgTune: hdType: ssd patroni: dynamicConfiugration: random_page_cost = 10 will set random_page_cost to 10 even though it should be 1.1 according to pgtune. Other parameters will be set though as they're not overriden.

Other information: