API: should we disallow "undefined" parameters?

@dchiquito 's opinion from https://github.com/dandi/dandi-cli/pull/911#issuecomment-1040651874 :

> I personally think that specifying undefined parameters is undefined behavior, and ignoring them is a perfectly valid way of handling them. If you think otherwise feel free to file a dandi-archive issue

I don't disagree that it is a "valid way" as long as we say that it is a "valid way" ;) but the question for me is either we should keep it "valid"?

seeming *pros* from allowing undefined to just be ignored

- easy to add support for making API more restrictive, e.g. add a parameter which earlier was not required. `dandi-cli` could just adjust to provide additional parameter without even awaiting for server to have support for it -- that parameter would simply be ignored by server until "not".

*cons*:
- a typo in a parameter name specification of optional parameter would just make it silently ignored, resulting in incorrect/unexpected operation without any error code
- feels wrong to just silently allowing/ignoring arbitrary parameters (that is not how API works, unless all functions have `**kwargs` at the end of their signatures, and AFAIK nobody does that)

I wonder what other APIs do?

Just wanted to initiate the discussion

edit:
- a more 'proper' way IMHO would be for client to add/or not some parameter is based on some information from API server on its version of supported functionality. Unfortunately due to #222 we do not even know what version of the API server we are talking to.

No implementation files or tests are named. Start by reviewing the referenced dandi-cli pull request discussion and issue #222, then locate how the API currently handles unknown parameters. Done means reaching a decided policy on rejecting versus ignoring undefined parameters and documenting or testing that behavior.

Written by the indexing model from the issue text.