Validate assumptions about Compliance in CustomersDot

### Background

The ~"group::fulfillment platform" team is looking to improve contact management in CustomersDot as part of https://gitlab.com/groups/gitlab-org/-/epics/9831+.  In this epic we will be introducing the concept of BillingAccount Contacts to CDot which will store data about the Bill To and Sold To Contacts for a BillingAccount.  More details can be found in this [proposal doc](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/doc/architecture/contacts_management_proposal.md).  This new concept will have an impact on Compliance in CustomersDot.

Compliance is performed in CDot in a few different ways at the moment:

1. Visual Compliance (Sanctions Screening Tool)
    - This tool screens purchaser information (name, country, and state (for USA/CAN purchasers only) against various sanctions and denied party lists, supplied from SFDC and creates an export hold in SFDC when a) a potential match is detected and/or b) for purchases originating from high risk countries. This screening occurs when an opportunity or quote is created in SFDC. 
    - This tool was briefly enabled in CDot in 2021 and then disabled because it blocked more purchases than expected (unnecessarily). For this reason, web direct purchasers are currently only screened post-purchase. 
    - Visual Compliance will be replaced by a new tool, Navex Risk Rate, in April 2023 in SFDC. Visual Compliance will be retired shortly thereafter. We plan to subsequently enable Risk Rate or an equivalent for web direct purchases, however, the plan is not yet defined. In the meantime, Risk Rate will screen these purchasers, post purchase as Visual Compliance does currently. 
    -   See [issue](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4857) to remove Visual Compliance for non-Marketplace usage.
2. EmbargoChecker service
    - An internal control implemented per [Issue 4166](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4166), the [`EmbargoChecker`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/43b599e2dc1d52d074d97da549167c2b44a8bf69/lib/embargo_checker.rb) verifies if a Customer's country or IP location is Russia or Belarus before allowing important actions, like updating or renewing a Subscription. 
    - This control ensures compliance with trade control laws implemented in response to the Russian invasion of Ukraine. It, for example, prevents the customer's independent renewal of self-managed subscriptions, which are in most cases prohibited by export control law; and allows Legal an opportunity to identify, on a case-by-case basis, exceptions to that general prohibition, to screen individual customers in Visual Compliance/Risk Rate pre-purchase, and to screen the purchasers' paying bank (many of which have been sanctioned).  
    - Note: the Embargo Checker is country-based and does not consider whether any given purchaser is identified on a sanctions list. 
3. Country validations on Customer record
    - This validates the `country` field for a Customer record is not included in a hard-coded list, [`World::COUNTRIES_TO_REJECT`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/f628a9a0ffc0d6a99181684bab3c417eb671d1a7/lib/world.rb#L32).

As seen above, the Customer record is used heavily for compliance, but as we introduce Sold To Contacts into CDot, this seems like the more appropriate object to use for Compliance checks.

### Questions

Before going to far down ~"workflow::solution validation", we'd have some questions for ~"group::compliance".

1. Thinking about the sales-assisted flow, if SFDC / Zuora have customer data for embargoed countries/companies, and sends a callout to CDot for provisioning, should it be allowed?
    - For example, if CDot receives a callout where the SoldTo contact has a country of China, should CDot continue with provisioning access?
2. What entity should be considered when thinking about compliance?
    - Is it the individual that’s logged in (Customer) or the BillingAccount they belong to (SoldTo)?
    - How is this done in SFDC? Is it based on Account address? SoldTo Address?
3. What is the latest plan for RiskRate?
    - Status update?
    - How do we plan to use it for information generated via CDot (i.e. web direct flows)?

### Results

Once we have answers to these questions, we can confidently update the [contacts management proposal doc](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/doc/architecture/contacts_management_proposal.md) and create more issues for https://gitlab.com/groups/gitlab-org/-/epics/9831.

Story points: 2.0