Refuse a field name that is not a field

[ramonski]

Builds on #115, and has to: a name a Dexterity type kept from its Archetypes days must reach its field before unknown names can be refused, or every payload written against the documented API would be refused instead.

A name in a record that matches no field and no setter is dropped with a line in the log, and the request answers that the object has been created or updated.

Current behavior before PR

POST /create {"portal_type": "AnalysisProfile", ...,
              "Service": ["whatever"], "Nonsense": 42}

200 {"count": 1, "items": [{..., "services": []}]}

Both keys are gone and the caller is told all is well. This is how an afternoon goes missing: the typo was Service for services, a spec reported fifty-eight objects composed, and the profile it had just written stayed empty.

The code says so plainly:

            if success is False:
                logger.warning("update_object_with_data::skipping key=%r", k)
                continue

DexterityDataManager.set returns False when it finds neither a schema field nor a setter for the name.

Desired behavior after PR is merged

400 {"message": "No objects could be created: No field named 'Service' on
                 AnalysisProfile. Did you mean 'services'?", ...}

Without a field close enough to suggest, it says only what it knows:

400 {"message": "No objects could be created: No field named 'Nonsense' on
                 AnalysisProfile", ...}

The suggestion comes from difflib.get_close_matches over the object's own field names.

The keys that are not fields

A record also carries keys that address the object or steer the request, and those must not be mistaken for fields. They are named now, where only id was before:

CONTROL_FIELDS = ("id", "parent_path", "parent_uid", "path",
                  "portal_type", "transition", "uid")

That list is the set of keys the routes themselves read out of a record.

A note on what this changes for callers

A payload carrying a key that is not a field is refused where it used to be accepted. That is the point, and it is worth saying out loud: an integration that sends something extra and harmless will see a 400 it did not see before. The alternative is what we have today, which is that a typo in a field name is indistinguishable from success.

Verification

• bin/test-senaite -s senaite.jsonapi: 41 tests, 0 failures, 0 errors, run against a tree carrying Validate only the submitted fields on update #107, Fix single valued Dexterity UID references not settable #115 and this change together, which is the combination that matters.
• uidreferences.rst covers both messages, the one with a suggestion and the one without.
• Checked that the BBB names the package's own create.rst uses throughout (Department, Category, Methods, Method) still go through, which is what makes Fix single valued Dexterity UID references not settable #115 a prerequisite rather than a convenience.

I confirm I have tested the PR thoroughly and coded it according to PEP8 standards.