The Put User API currently accepts a password_hash as an alternative to password, when creating or updating a user.

We don't document this, nor do we validate that the hash being stored is supported by the cluster.

We should:

• Add validation in the Put User action that the incoming hash is one we understand (and not NOOP). See Hasher.resolveFromHash
• Add tests for this
• Add it to the API documentation

The use cases for using hashed passwords in the API are:

• replicating users (and passwords) from other stores (or other clusters) that support compatible hashing schemes.
• improved security in automation tools (e.g. ansible) - the automation scripts can store a hashed password rather than a clear text one
• extreme end-to-end security in user setup (ES never sees the clear text password)
• efficiency in bulk user setup. Password hashing is one of the slowest parts of user creation. This can offload that work to the client.