Make installation using RDS work cleanly

[timabbott]

Following #13105, it's now reasonable to use Zulip with a remote postgres database service like Amazon RDS. However, there are a few things that are awkward about the setup:

• The POSTGRES_MISSING_DICTIONARIES configure is passed via an environment variable, which can result in issues if folks run the instructions at the end of scripts/setup/install --remote-postgres rather than remembering to pass the flag each time. I think what we should do is make --postgres-missing-dictionaries option set a value in the postgresql section called missing_dictionaries = trueviacrudini, and have the database initialization code read that using e.g. get_configfromzproject/settings.py` to determine which mode to use. This would also expose the fact that we're in such a configuration to Zulip if we wanted the UI to show anything about that state.
• This is longer-term. The management of which puppet classes to enable in the install script is definitely showing the limitations of the current shell-based system. The user-visible problem here is that the instructions end up installing a local postgres server and make you manually disable it, which sucks. The root cause is that we're still including the full voyager.pp set of puppet rules, even though we actually don't want to include all of those manifests. There are two potential paths forward here. (1) is to make voyager.pp support reading some options like enable_postgres = false in /etc/zulip/zulip.conf that is can use to determine whether to include a postgres server, and then the install can have options like --no-postgres that just set those options when writing out the original /etc/zulip/zulip.conf. (2) Is to have the installer write out the individual puppet role classes. I think that latter approach may be a worse choice in that it gives us less flexibility to refactor the puppet class hierarchy over time.

[zulipbot]

Hello @zulip/server-production members, this issue was labeled with the "area: production installer" label, so you may want to check it out!

[hackerkid]

The first part is completed.

[timabbott]

@alexmv to what extent did the recent puppet to add profile classes make the remaining task for this project complete? I think it's possible we might just need to document an install invocation with some puppet classes specified for use with RDS, but it probably needs testing.

[alexmv]

I think that's accurate, but I think it certainly needs testing.

[asah]

is this still high priority? from reading, it feels medium/low given that it's a small hassle in the grand scheme of production installs.

does this affect other hosted Postgres installs? e.g. GCP postgres, Azure postgres, Heroku

do we want to support aurora and other postgres-compatible hosted databases? (should be easy)