Present Debusine to the Debian Security Team

MUST: reach out to the Debian Security Team to present and validate design ideas, and perform user and task analysis to identify pain points with the old infrastructure and key features in the new one

Similarly to #358 (closed), we should start by identifying which relevant features we designed in Debusine, and which pain points we expect the security team to hit.

Discussion points:

• How would embargoed uploads work?
  • I'm imagining we'd create a private workspace for the security team to host a $release-proposed-security suite in.
  • With an ACL (#395 (closed)) that would permit uploads by any project member (and DM...), to a queue for review (#399 (closed), #398 (closed), #402) by the security team.
  • Once built, reverse dependencies can be scheduled automatically, as britney does (#397 (closed))
  • Then, once verified, packages could be copied (#396 (closed)) to the $release-security suite in a public workspace.
• How would we ensure the privacy of embargoed uploads?
  • Possibly by restricting the security suite to a small number of extra-trusted buildds? (#405 (closed))
  • The debusine server database and its file store, would hold embargoed information. How big of a problem is that?

Please continue to add to the above