User-specified partial charges should not be automatically adjusted by `GAFFTemplateGenerator`

[epretti]

As we recently discussed, GAFFTemplateGenerator will shift partial charges to match molecule formal charges because those output by antechamber can be slightly offset (looking into it a bit, this seems to be coming from some kind of rounding somewhere within antechamber). This is a problem because it can silently adjust user-specified charges. I am opening a separate issue for this because there are a few additional things related to openmmforcefields' use of OpenFF that hopefully @j-wags / @mattwthompson will have insight into:

1. It appears that the OpenFF toolkit now handles the GAFF issue automatically, according to Round partial charges to enforce correct integral charge on molecule openforcefield/openff-toolkit#456. Am I understanding correctly then that as long as the default normalize_partial_charges=True is present on assign_partial_charges(), openmmforcefields shouldn't need to do its own normalization at all?
2. openmmforcefields' _molecule_has_user_charges() checks if the OpenFF toolkit Molecule has partial_charges equal to None, or if they are all 0, to decide if there are no user charges. This precludes users from explicitly specifying all-zero partial charges, and a comment points to the issue Add convenience method to Molecule to return whether user has provided partial charges openforcefield/openff-toolkit#488 from 2020. Is this still the state of things now in the OpenFF toolkit, or is there a more robust way to check for the presence or absence of user charges?

[j-wags]

Am I understanding correctly then that as long as the default normalize_partial_charges=True is present on assign_partial_charges(), openmmforcefields shouldn't need to do its own normalization at all?

I believe this is correct. That is the OpenFF Toolkit's default behavior, and quickly searching uses of assign_partial_charges in the OpenMMForceFields source code shows that this default is never overridden.

openmmforcefields' _molecule_has_user_charges() checks if the OpenFF toolkit Molecule has partial_charges equal to None, or if they are all 0, to decide if there are no user charges. This precludes users from explicitly specifying all-zero partial charges, and a comment points to the issue openforcefield/openff-toolkit#488 from 2020. Is this still the state of things now in the OpenFF toolkit, or is there a more robust way to check for the presence or absence of user charges?

The meaning of an OpenFF Toolkit Molecule's .partial_charges attribute depends heavily on context (sometimes it's just used as a container when converting between molecular representations, where we try to preserve the distinction between undefined/none/zero), and our default behavior is to NOT use it during parameter assignment unless the user specifically asks (forcefield.create_interchange(topology, charge_from_molecules=[mols]). So unfortunately, just looking at an OFFMol with no additional context, there isn't a clear concept of "user charges" (that is "charges that the user expects to be assigned to a molecule even if they disagree with a force field's charge method") that we can provide for OpenMMForceFields.