Support RSA key store/generation

Add RSA public/private key store/generation to Barbican

Users should be able to store and generate public/private keypairs in Barbican. There are multiple ways this can be implemented :

Option 1:
We can modify secret endpoint to accept two payloads specific to rsa keys. We would have an identifier for the payload (public/private). We don't want users to provide their own identifier for the payload in case we want to list all public keys for a tenant, etc. If "algorithm" field is set to "rsa", then user would have to provide payload for public and private key.

Users would have to provide 2 payloads with the secret metadata, or user can just create the metadata, and provide 2 payloads with the PUT call.

Users can generate the keypairs making a call to orders api, with algorithm set to "rsa". Order endpoint would create a secret and payload for public and private key.

*These changes would require us to make changes in the secret endpoint therefore we would need to implement these as part of the v2 api.

Sample request :

{
  "name": "sample_rsa_keypair",
  "expiration": "2014-02-28T19:14:44.180394",
  "algorithm": "rsa",
  "bit_length": 2048,
  "payloads" : [
   {
  "type" : "public_key",
  "payload" : "gF6+lLoF3ohA9aPRpt+6bQ==",
  "payload_content_type" : "application/octet-stream",
  "payload_content_encoding" : "base64"
 },
   {
  "type" : "private_key",
  "payload" : "gF6+lLoF3ohA9aPRpt+6bQ==",
  "payload_content_type" : "application/octet-stream",
  "payload_content_encoding" : "base64"
 }
  ]
}

Option 2
Create one to one relationship between secrets and also add "type" and "secret_ref" field. Users have to provide predefined types for their secrets, in RSA key case types would be : "public_key", "private_key", "private_key_ passphrase". In Option 1, "type" was the part of payload, in this one "type" and "secret_ref" would be part of the secret metadata, and secrets would have only one payload. (instead of array of payloads in Option 1).

Users should be able to create each of these secrets without providing any "secret_ref" information.

Validation rules :
If "algorithm" is set to "rsa", user would have to provide "type" field.
If secret_ref info is provided for secret type = private_key, matching secret type has to be "private_key_passphrase"
If secret_ref info is provided for secret type = public_key, matching secret type has to be "private_key"

Orders api:
Orders api would create 2 secrets, one for public and one for private key, and set secret_ref of the public key to uuid of private key.

Option 3:
Create containers for secrets (Details : https://blueprints.launchpad.net/barbican/+spec/crud-endpoints-secret-container)
Add type field to secret metadata
If "algorithm" is set to "rsa", user would have to provide type for the secret which can be "public_key", "private_key" or "private_key_passphrase".

This approach will allow us to store RSA keys without having relation model in secrets.