feat: use a braze api-triggered campaign for ent offer usage

[iloveagent57]

Required Testing

• Before deploying this change, complete a purchase in the stage environment.
  (^ We can remove that manual check once REV-2624 is done and the corresponding e2e test runs again)

Description

Modifies the send_enterprise_offer_limit_emails command , it now:

• pulls offer usage data from the analytics API service, to be consistent with our stance that our warehouse-based enterprise learner progress report, and its derivatives, are the source of truth about offer state from an accounting perspective. Does this only for "Booking" types of offers, not offers with max_global_applications > 0.
• Makes the email body a dictionary of key-value pairs consumed by a braze email template, rather than a string.
• Blocks until the underlying email celery task is done (which is ok b/c this is run from a mgmt command; and I'd rather not write an OfferUsageEmail if the related task actually fails).

Related changes in ecommerce-worker: openedx-unsupported/ecommerce-worker#169

https://2u-internal.atlassian.net/browse/ENT-5940

Testing instructions

Check out openedx-unsupported/ecommerce-worker#169 and make sure you've got ecommerce-worker mounted in your {DEVSTACK_WORKSPACE}/src directory.

From ecommerce shell, do:

pip install -e /edx/src/ecommerce-worker
export WORKER_CONFIGURATION_MODULE='ecommerce_worker.configuration.devstack'

• Then check logs to make sure ecommerce devserver is restarted.
• Ensure you have an Enterprise Offer record with email addresses filled out - make it an email address you actually use, because Braze will really send you an email. Prefer to do this with an email/user that already exists in the Braze dev account.
• Ping @iloveagent57 for a copy of his ecommerce-worker private.py file.
• Ensure analytics-api local service is running.
• make analyticsapi-shell
• Ensure you run the script to seed toy analytics offer data for your test enterprise customer uuid: ./manage.py create_enterprise_offer {customer-uuid}
• Back in ecommerce-shell, run ./manage.py send_enterprise_offer_limit_emails

Other information

Include anything else that will help reviewers and consumers understand the change.

• Does this change depend on other changes elsewhere?
• Any special concerns or limitations? For example: deprecations, migrations, OpenEdx vs. edx.org differences, development vs. production environment differences, security, or accessibility.

[long74100]

just the question about how retry exceptions will be handled, not sure if we already found that out.

[iloveagent57]

I just locally forced the task to retry once before doing the actual work - raising self.retry(...) didn't fail the mgmt command and everything worked as expected. The downside to propagate=False here is that every other task behind the retried task has to wait for the retry to either succeed, or to exceed the max number of retry attempts (currently set to 6).

[iloveagent57]

but....the retry countdown is currently set to 3600 seconds. So I'm going to change that for this specific task, maybe to 10 seconds.