Validation - Address about test-at-home HOT 7 OPEN

Blocked on USPS requirements and procurement of address validation provider (eg Smarty)

from test-at-home.

Dependent on #57

from test-at-home.

@porta-antiporta One thing we should specify is desired behavior if validation API is not working (just save? sanity checks on specific fields?)

from test-at-home.

@hartsick if validation API is not working then we should throw an error (if transient failure for one user) or stop taking orders (if complete outage). Sanity checks aren't sufficient as we have to confirm deliverability before saving an order.

The latter is undesirable, but we can't store an order without validating the address for deliverability as we are unsure if we can get a hold of the user in the future. So if we think validation API is not reliable, we should be thinking about redundancy/fallback options (offline USPS? pinging online USPS?).

from test-at-home.

Opened #60 seeing resiliency of API is likely pretty meaty in and of itself. (And likely not ready by Th).

from test-at-home.

Updated to AC reflect findings from #57

from test-at-home.

@porta-antiporta I think that this is done based on what we had discussed. We're still waiting on contract from Smarty, so using developer accounts with limited rates for time being. Here is the approach we went with for now:

Normal path

1. Javascript check for deliverability. Requester sees different errors for no matches found for their search and if there is a match found but it's dpv_match_code of D. We could probably use better error messages for latter
2. On final submission, server-side check for deliverability. Requester will see same errors as described in Javascript above (though they shouldn't see them if they have Javascript enabled)
3. We do not correct the address. Instead, we save what the requester input and save whatever came back from the server, so we can reference when sending to USPS.

API erroring path
If for some reason the API gives an error, we skip the address validation for that request (so, if front end call errored they may still get caught by server-side validation). If it is the backend validation that errored, we accept the request but mark that the address was not validated in the database (attribute address_validated=false). This should handle any intermittent errors, such as a temporarily unavailable service or a cooldown for exceeded rate limit.

Support for turning off Smarty
This is still in-progress (as part of #67), but right now we allow for turning off server-side validations entirely (so that we can deploy a parallel application). We still need to allow disabling front-end address validations.

from test-at-home.