Deprecate subdivision-level postal code validation

[bojanz]

Right now we validate postal codes using two sets of patterns, the country-level pattern which matches the full postal code, and subdivision-level patterns, which match a prefix. This means that there can be up to 4 patterns evaluated: country-administrativeArea-locality-dependentLocality.

Over the years this has caused problems, because keeping so many patterns up to date isn't easy. We frequently get updates for subdivision-level patterns. This means that we cannot guarantee that patterns on that level are precise/correct, which can block a user from entering their address. #142 was a recent case of that type.

Furthermore, the validator currently sets the same error regardless of which pattern fails, giving the user no indication if the postal code is generally invalid, or just invalid for a selected province or district. This is tracked as a bug on the Drupal side: https://www.drupal.org/project/address/issues/2828128

On the other hand, I am not sure there is a large gain in ensuring the postal codes are THAT valid. It's still not a guarantee that the postal code exists (VS just "looks correct"), nor that the address exists in that postal code (sites use an address verification API for that).

We now have a choice to make. Either we expand the validator to use different error messages or... we remove subdivision-level postal code validation completely. This would significantly reduce the size of the dataset and simplify the validator code, while removing issues with validation errors and insufficiently maintained partial patterns.

[jamessampford]

Could there be something like a validation level set for postal codes, for example, the level could be (smallest to largest):

• subdivisional level
• national level (ie. matches the basic patterns)
• do not validate

Where the requested level does not have any patterns, it falls back to next level, and so on

A use case in mind could be that you want to make your own data as accurate as possible and skip front end checks for the smallest level but use the smallest level for back office checks. A back office system could easily flag addresses that may need to be checked/investigated at the smallest level (or call the customer to check) and amend the data if need be.

I do like the exception/error messages that have been suggested and would prove useful

[bojanz]

I have received positive feedback from the Drupal side about no longer doing subdivision-level validation, so I'm proceeding. The commit just deprecates the relevant code, since we don't want to break existing installs.

I like the idea expressed by @jamessampford but ultimately I am not willing to devote the energy to make it happen and maintain it going forward.

This change is good prep for 2.0.0, which will get us closer to bojanz/address (the Go version of this library) by reducing the amount of data needed to define a subdivision, and allowing the community to send in PRs with their own subdivision data, independent from Google.