Http 400 when user enabled is not a boolean

When creating or updating a user, no type check was performed on the
enabled attribute. Therefore, if enabled value in JSON/XML is not a
boolean buta string or an int, keystone responds with an incorrect
Http 500 error code and the stacktrace.

The change introduces a type validation of the enabled attribute
at backend and api layer. If the type is not a boolean, keystone
now returns an appropriate Http 400 error code with a message
pointing a bad format for the attribute.

Test cases have been added to file test_backend and
test_content_types for testing the case when enabled attribute is a
string or int when creating or updating user.

The same correction can be done for create/update projects, domains.

Change-Id: I7d2fe3acf0c4dbd3ce5bdf9f4d059df085853b84
Fixes: bug #1110435
Accept env variables to override default passwords

Preserves the default passwords corresponding to the OpenStack Install
and Deploy Manual while allowing environment variables to specify user
provided passwords. As well, a single common password for all the service
users can be specified using the SERVICE_PASSWORD environment variable.

This fix restores compatibility with the version of this script released
in Folsom where the environment variables could override default passwords.
It also preserves compatibility with the fix for bug 1073291 that brought
the script into line with the docs (but unfortunately broke backwards
compatibility).

There is no warning emited if the user does not override the default
passwords as was present in Folsom, but not in Grizzly. This makes the
fix output compatible with Grizzly only. Note that the logic for warnings
pre-Grizzly was unclear. The script is, however, clearly named "sample"
and warnings are present in the comments.

Change-Id: I927fcddf04dcb87e5c9252f0874939b17f3c4809
Fixes: bug #1166182
extracting credentials

Moves the credentials API into its own backend.

LDAP was not going to be able to support credentials.

Even with a custom schema, many people are using LDAP in read only
mode, which means that they would not be able to use the  credentials
API at all.  By splitting it out, we have a workable solution for
both SQL and LDAP Identity backends.

Drops the Foreign Key constraints off the Credentials table, as there
is now no guaranttee that users are stored in the same backend.

Blueprint extract-credentials-id

Change-Id: I10ad4b36c6f03d1712621eaffcfefa48a5453aff
Merge "Http 400 when user enabled is not a boolean"
Merge "extracting credentials"
Merge "Accept env variables to override default passwords"