Replication secret encrypted in Web-UI

[phillxnet]

Prior to "Update django-oauth-toolkit #2710" #2727 we stored our CLI app secret in the database: and exposed that value within the Web-UI (to admin Web-UI users) for use in replication. However the linked PR introduced a replication regression contextualised in "Replication regressions #2748".

It is proposed that, given the recent resolution of:

Issue: "Adopt dedicated secrets management library" #2728
PR: "Adopt dedicated secrets management library #2728" #2758

has again returned us to an install static CLIENT_SERCRET, we can approach the issue of surfacing this secret within the Web-UI again, and not in its current hashed form: an artifact of upstream changes in django-oauth-toolkit.

[phillxnet]

Ongoing progress with this issue:

We already special case our auto-created cliapp, and the referenced changes regarding our new inability to retrieve raw secrets from the DB: as per upstream django-outh-toolkit changes, making our existing credentials input for external applications no longer fit for purpose: in that we silently auto-create secret access keys. See spin-off issue: Surface auto-generated access key secrets prior to save #2763

But for out cliapp it is proposed that we extend its 'special case' to expose the auto-generated secret (now again install static) within the Web-UI; while continuing to no longer surface 'other' custom api key entries.

[phillxnet]

The in-development Web-UI proposal is as follows:

Note the terminal pass command indicating our cliapp secret from the command line.

That is we surface our internal app's secret, but indicate all others as encrypted; with text explaining that they are only available during creation. I.e. we special case our cliapp as that is the only one we must preserve our knowledge of due to it's internal use nature. We need to authenticate against ourselves, and this same cliapp secret is a go-to for easing the setup of replication.

[phillxnet]

Closing as:
Fixed by #2764