Goal: 

• APIs to bulk import/export all fields for the custom repositories specified 
• These will be used to share custom repositories across orgs (requested by Envision)
• Notes from our meeting on this: https://docs.google.com/document/d/1P2EvpnKwrvwlktIoAQlEmpVjfBhkXvtpZPynrkG45js/edit#heading=h.c1bx7nk3zlb5

Acceptance Criteria:

• Endpoints for bulk import/export of custom repositories (maybe something like POST /repositories/bulk_import and POST /repositories/bulk_export) 
• bulk export would take in a list of repository UUIDs to export
• Successful response for export should return array of structs with all repo fields necessary to recreate them:

           distribution_arch,
           distribution_versions,
           gpg_key,
           metadata_verification,
           name,
           snapshot,
           url,
           module_hotfixes,
           origin

• Bulk import should be done in a transaction and either import all or none
  • if a repo already exists by URL, don't try to create, don't update, just return it with any mismatches among version/arch/gpg key, etc...
• Request for import should include all repo fields (likely the response from the export), successful response should return all the repos imported (confirm what should be included in response)
• On error, return error structure with error message(s) and which repo(s) had the error
• An integration test exists that tests importing and exporting
• response should include list of  [create/existing repo, warning messages]
• Talk to anna and determine whether we should  error, update, or ignore existing repos (by URL)
  • Ideally they would want a diff, the goal is change it to the previous state. If, for example, the blueprint was not properly saved, they would delete the created repositories, and edit the edited repositories to the previous state 
  • For MVP, a warning (and possibly which fields are different) would be enough
  • Existing bulk_create would not work as they may need to create repos that already exist