investigate tying bucket definition to a particular user mapping plugin

[trel]

This was initially conceived as an addition or complement to a request for buckets to be designated as 'public'.

The initial design was just to add a "public": true/false in the bucket mapping alongside the collection name. This would have implicitly 'skipped' user mapping because "public" would map to the "anonymous" user for all iRODS connections.

However, to make this more generic, we then considered a new user_mapping plugin named "public" or "anonymous" that would do this work and have the bucket map point to it... something like...

"<bucket_name_1>": {
    "collection_path": "</path/to/collection_1>",
    "user_mapping": <user_mapping_plugin_name>
},

This suggests a new design...

• there can be a single bucket mapping plugin active in an S3 API install
  • currently just our file-based solution, with an updated schema
• there can be multiple user mapping plugins active in an S3 API install
• each bucket map can point to a single user mapping plugin

This issue would define the new bucket mapping schema, paying attention to legacy installs (defining a default "user_mapping" as "s3_keypair" perhaps), and the creation of 2-3 new user_mapping plugins.

These new user_mapping plugins could be:

• "s3_keypair" - the current user_mapping-local_file could be named more specifically
  • maps a keypair to "who"
• "public" - all iRODS connections would use the "anonymous" user
  • maps everyone to an identical "who"
• "token" - nearly identical to "s3_keypair", but just a single token string
  • maps a "secret" to "who"
• "instance" - would map incoming client "hostname" (and maybe something else) to iRODS user
  • maps a "where" to "who"