Require implementations to throw errors if options (post bodies generally) are not understood

[dlongley]

This is particularly important to enable smooth upgrade paths to add new features by ensuring that post bodies that are not understood will result in errors -- so that clients can detect that certain features are not available in an implementation.

We should state this generally but also have tests for individual endpoints. For example, posting a non-empty body to start an exchange -- for an exchange that does not understand anything but an empty post body -- should result in an error.

[msporny]

The group discussed this on the 2024-06-11 telecon:

@PatStLouis asked if this was about undefined options, or for existing options. @msporny noted that it's for both; it's for any data, option, or option value that the API endpoint does not understand or know how to process.

There were no objections to ensuring that API endpoints default to throwing errors when they receive data, options, or option values that they don't understand.

A PR needs to be raised to instruct implementers that they MUST throw errors when they receive data, options, or option values that they don't understand.