Incorrect use of hash-based types/annotations for secrets that implementations must recover cleartext

[earies]

Several leafs across the model-set assert that a secret is stored as a one-way
hash but the feature consuming that secret requires access to the original
cleartext variant at runtime.

A salted one-way hash can't satisfy the consumers of this data so the leafs in
question are unpopulatable - note: this is distinct from the legitimate uses of
hashing for login credentials where the element only ever verifies a value and
never has to reverse/recover it.

Offending Paths (Both config/state)

Path	Type / construct	Cleartext required at runtime	Verdict
/system/aaa/server-groups/server-group/servers/server/tacacs/config/secret-key-hashed	crypt-password-type	Yes	Wrong
/system/aaa/server-groups/server-group/servers/server/radius/config/secret-key-hashed	crypt-password-type	Yes	Wrong
/ha-groups/ha-group/config/ha-key-hashed	crypt-password-type	Yes	Wrong
/ha-groups/ha-group/config/ha-key	string (Prose: "expected to be hashed by the firewall")	Yes	Wrong
/system/aaa/authentication/admin-user/config/admin-password	string + openconfig-hashed-value	No. Verify only	Correct
/system/aaa/authentication/admin-user/config/admin-password-hashed	crypt-password-type	No. Verify only	Correct
/system/aaa/authentication/users/user/config/password	string + openconfig-hashed-value	No. Verify only	Correct
/system/aaa/authentication/users/user/config/password-hashed	crypt-password-type	No. Verify only	Correct

Which shows there are 4 constructs that assert irreversible

1. oc-ext:openconfig-hashed-value: "Hash algorithms are by definition not
   reversible... the device never reports a cleartext value, even if the input
   is provided as cleartext"
2. oc-aaa-types:crypt-password-type: "Unix crypt(3) form
   $<id>[$<param>=<value>...][$<salt>[$<hash>]], ids 1=MD5, 2a/2y=Blowfish,
   5=SHA-256, 6=SHA-512. All salted, all one-way."
3. -hashed leaf-name suffix
4. Description prose mandating hashing with no proper type backing

Potential Solutions

1. Introduce a new "reversible-secret" type

They exist in reality and implementations need them - we likely don't need to
cover all the variations but a generic typedef w/ proper description should be
sufficient.

We could add a companion leaf stating the "format" of the secret if necessary
(type9, etc..)

2. Deprecate and replace the offending leafs

For the ones listed above as Wrong, confirm implementations use/not-use,
mark as deprecated and introduce a new leaf w/ the new type representing a
reversible secret.

3. HA Related

This description/typing is just too loose. I'm unsure of implementation status
on this modeling.

4. Tighten state containers

Since we reuse groupings under config/state for intended/applied, this
implies that accepting clear-text could be read back which is not the intention.
For this, it is probably worth revisiting these cases in what should be in
config vs. state containers

e.g.

  ./config/secret-key => cleartext
  ./state/secret-key-reversible => obfuscated