Send Incident images to Status Page s3 Bucket on publish

What does this MR do?

Overview

The Status Page is a static website deployed to a users public s3 bucket.

This MR moves existing files in an issue description or comments to s3 for display on the status page.

This is the last MR that is part of: #205166 (closed)

Technical implementation

We move the files to s3(in this MR) and run a post processing job to correct the html(in another MR).

All of the code to upload files to s3 runs async via a sidekiq job. A publish job is triggered when an issue is updated.

Because files might be large this uses Muilt-part upload to send uploads to the status page s3 bucket.

We limit the user to 5000 attachments in s3 per issue.

This is the last MR that is part of: #205166 (closed)

TODOS:

• Docs
• Changelog
• Correct object storage to use GitlabUploader.open and multipart upload
• Confirm with large file that multipart is happening correctly
• Use UploadFinder in UploadsRewriter
• Confirm with object storage enabled on dev stack
• Re-Confirm without object storage enabled on dev stack
• Only transfer that which does not already exist
• Respect limit
• Specs
• Self Review

Testing

Once a status page and a project with some incidents is setup one way to quickly test the unit in the rails console is:

# Publish all
project = Project.where(id: 5000139).first
issues = project.issues.all
issues.each do |issue|
  user_notes = issue.notes
  StatusPage::PublishDetailsService.new(project: project).execute(issue, user_notes)
end

# Unpublish all
project = Project.where(id: 5000139).first
issues = project.issues.all
issues.each do |issue|
  user_notes = issue.notes
  StatusPage::UnpublishDetailsService.new(project: project).execute(issue)
end

Screenshots

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• [-] Tested in all supported browsers
• [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• [-] Label as security and @ mention @gitlab-com/gl-security/appsec
• [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• [-] Security reports checked/validated by a reviewer from the AppSec team