Allow any attributes in mapping

When using attribute mapping (e.g., user_additional_attribute_mapping), any
attributes that Keystone didn't know about were ignored and a warning was
issued, like

 WARNING keystone.common.ldap.core [-] Invalid additional attribute mapping:
 "description:description". Value "description" must use one of password,
 enabled, default_project_id, name, email.

This check is removed. Additional attribute mappings for "unexpected"
attributes (such as description) should be allowed. For one thing, all the
known attributes already have a way of setting the mapping, via the
user_*_attribute config option. This will allow setting a "description" or
any other attribute mapping for users.

Change-Id: Idc2cd75ecd3e1a06a50fd0a676d83c5de74ca7a5
Partial-Bug: #1293698
Remove LDAP password hashing code

Keystone should not be hashing passwords for LDAP users
itself.  Password hashing should be performed by the LDAP
server, as password policies may not allow pre-hashed
passwords to be set (they may enforce a scheme that is
stronger that salted SHA-1).

This removes the LDAP password hashing code.  When using
fakeldap for running unit tests, passwords will not be
hashed.  For this reason, the hashing tests are skipped
for LDAP backends.

Closes-bug: 1308793
Change-Id: Ia0998b7fd8fb5d01b86a947d18b7e79fcffd1228
More efficient DN list for LDAP role delete

The search to get the DNs in RoleApi::delete would return all
attributes for the entry rather than just the DN.

This fix uses the special attribute name 1.1 to indicate that
no attributes should be included in the response.

Change-Id: Ifac101cb1e145050ee9a517c47b6bd4fea99ffa5
Merge "Allow any attributes in mapping"
Merge "Remove LDAP password hashing code"