Run integrations as background jobs

[ajkiessl]

The integrations are already set up with ActiveJob, so hopefully it's not too hard to implement this. Right now, if you run an integration from the UI, the integration process is ran synchronously with the request. So, the HTTP request times out and returns an error to the user. The integration still runs, however, so this isn't a major issue. It does lead to some confusion, since users are constantly getting errors that aren't important. We should have these jobs run asynchronously, and return an immediate response to the user letting them know the integration is running after starting an integration.

[Smullz622]

Started this with #122 The complicating factor is that perform_later does not accept the same arguments as perform_now, including ActionDispatch::Http::UploadedFile which is how the file is passed in params. What I currently have works but it is only complete for create users integration & could use refinement. We probably want to think about our overall strategy on how we're passing/storing files now that jobs are going to be queued up vs run immediately.

This will also potentially impact how other integrations requests are blocked when an integration is running. We still want them to be run in order one at a time, but if they're being queued, we can probably allow the next request to be submitted.

Also might want to ask Nicole if she wants some sort of notification when they're done/if they were successful. We're already sending her error notifications, so hopefully wouldn't be too difficult to modify that to send for all completed jobs & include errors if any.

[ajkiessl]

Some other things we'll need to add/consider:

• The fams_tools k8s deployments don't have an instance of redis configured. We'll need to get that up and running with these changes
• The sidekiq process will have to run in it's own pod in k8s, so we'll need that set up as well
• Similar to the issue we ran into with the pdf_accessibility_api, if we are going to process files in a background job, we'll need a file share mount to share files between the application and sidekiq pods
• It would probably be helpful in development to have all of this set up in the docker-compose.yml, but that's not a requirement to get this stuff released