Make `gitlab-ctl set-replication-password` easy to be used with automation

Problem to solve

GitLab Administrators want to be able to script and automate setting the Geo Replication Password with the ability to get feedback that the password has been changed.

Example:

/usr/bin/expect <<EOD
log_user 0
spawn gitlab-ctl set-replication-password
expect "Enter password:"
send "${rep_password}\n"
expect "Confirm password:"
send "${rep_password}\n"
echo "${rep_password}" > see_password.txt
EOD

Intended users

GitLab System Administrators

User experience goal

The goal is to automate the setup and configuration of GitLab Geo.

Proposal

Create an ability to set the password through the command line and ability to acknowledge that the change was made.

Further details

Feedback from GitLab Administrator:

I currently have no way of validating that the password I'm changing (setting the replication password) is reliably changing said password. I have no knowledge of any APIs that I can access to change or check the password. All I know is it would appear that this does not seem to work and without said APIs I'm blind to knowing what the issue could be.

In a discussion in our slack: https://gitlab.slack.com/archives/C32LCGC1H/p1589824906076900 (internal link), following the request from the customer:

The script adminname and I had been working on was building Gitlab in a replicated way following the instructions outlined here. https://docs.gitlab.com/ee/administration/geo/replication/database.html

If you have a script for the automation of this process that would help greatly. If you have a more effective way to automate that goes beyond bash scripting I'm all ears to that too.

Possible solution for confirming that it succeeded

ALTER USER returns ALTER USER, so if we see that output, then at least we know an error didn't happen:

sudo gitlab-psql -c "ALTER USER gitlab_replicator WITH REPLICATION ENCRYPTED PASSWORD '<replication_password>';"
ALTER USER

I suppose we could check for that output inside of set-replication-password. Though I would already expect set-replication-password to fail if ALTER USER fails. Does it not?

Possible solution for easier automation of set-replication-password

Make the command accept a password option as an alternative to using a prompt.