APIv4 - Limited support for casting

[totten]

Overview

Update the handling of top-level request options (AbstractAction::$foo) so that the magic setter behaves more like a simple setter.

ping @highfalutin cc @colemanw

Before

• setCheckPermissions(0) casts the 0 to false.
  • This is because it's a concrete setter with explict typing, so PHP rules kick-in.
  • Subsequently, APIv4 validation of $this->checkPermissions passes.
• setUseTrash(0) does not.
  • This is because it's a magic setter with no typing, so PHP rules don't kick in.
  • Subsequently, APIv4 validation of $this->useTrash fails.

After

• Both setCheckPermissions(0) and setUseTrash(0) cast the 0 to false.
• setUseTrash(0) does not support all the same conversion rules as PHP. It just supports the 0/1 rule.

Technical Details

I initially drafted in a way where setUseTrash() performed exactly the same casting as setCheckPermissions(), but there was a countervailing test to assert that setDebug('debug') is invalid, and that seemed fair.

[civibot]

(Standard links)

• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[highfalutin]

Thanks for jumping on this @totten. So, to be explicit about it, we're not accepting string 'true' or string 'false' -- can we make that clear in the cv help? see my docs pr

[highfalutin]

• General standards
  • (r-explain) pass
  • (r-user) pass: brings behavior more in line with user expectations
  • (r-doc) pass if document boolean params in JSON-ish Key-Value format cv#144 is acceptable
  • (r-run) pass: cv api4 Contact.delete +w 'id = 202' checkPermissions=0 useTrash=0 works as expected, and 1 also works in each of the bool params.
• Developer standards
  • (r-tech) pass: brings behavior more in line with (implicit) contract
  • (r-code) pass
  • (r-maint) pass
  • (r-test) pass

[colemanw]

Just pointing out that this whole issue would be moot if we bump our min php to 7.4 and can add type hints to class vars.