Create Users only when necessary

Summary

As a cloudigrade sysop, I want cloudigrade to track only Users that actively use its services so that we don't needlessly bloat the database. Currently, any HTTP GET request with a new account number in the 3scale header will result in a new User for that account number. We should only create a User when we intend to start tracking data for that User, such as when we process a new sources-api object from Kafka or when we use the legacy HTTP API to create a CloudAccount.

Acceptance Criteria

• Verify that HTTP GET requests to any of our APIs (in particular note the concurrent API) do NOT create a user.
• Verify that responses from our API for requests containing a user that we do not have return a simple 404.
  • Why 404 instead of 401 or 403? Because 404 helps minimize liability around leaked user data.
  • TBD Does this really make sense? Take a good look at the logic for checking org admin, and have a discussion with the team.
• Verify that HTTP POST requests to the legacy API to create a CloudAccount do create a user (if necessary) and return a normal response.
• Verify that processing a new sources-api object from Kafka does create a user (if necessary).
• QE to update and add new integration tests to ensure no regression for legitimate users with CloudAccounts and to assert requests for "new" users always return 404.

Assumptions and Questions

• This is a followup to #747 (closed)
• This idea came from Slack conversation here in which @infinitewarp observed 16736 new Users created in about 417 seconds due to a barrage of concurrent API requests from (presumably) the tally service. If tally service is regularly iterating through all known accounts, then we should limit the effect that otherwise "no-op" requests have on our back end.