improve the doc blocks in ApiCore

fix type parsing for more complex types

Do not directly use native function in API

As fedb87702391d74284af4d0c0add4330d3456195 showed, we can not directly
use native fuctions because they have no proper type hinting in PHP7.4

final set of API tests refactored

another set of api tests

Fix first set of API tests

First go at refactoring the API mechanisms

This introduces an ApiCall class that wraps around the actual method
that produces the result. This replaces various loose array structures
that provided t

First go at refactoring the API mechanisms

This introduces an ApiCall class that wraps around the actual method
that produces the result. This replaces various loose array structures
that provided the meta information before.

The ApiCall streamlines the aggregation of meta information between core
and plugin methods. Now all data is produced by Reflection based
introspection. Certain aspects can be overridden if needed. See
ApiCore::getRemoteInfo() for examples

This change removes the _getMethods() method from remote plugins and
introduces a getMethods() method. The two are NOT compatible as the
latter now returns a list of ApiCalls. However when looking at the
existing plugins, it seems that _getMethods() was nearly 100% obsolete
with the Reflection based default implementation. So most plugins will
not be affected at all. Some might now export one or two more methods
than before because of poor visibility settings (eg. not declaring
private/protected methods as such).

This change removes the RPC_CALL_ADD hook. Only a single plugin ever
implemented it. I'm not sure what this hook was supposed to do anyway.
Being able to declare arbitrarily named API endpoints seems wrong to me
anyway.

The new ApiCall now also supports passing named instead of positional
parameters. This will open up a new opportunity to get a proper openapi
spec running.

Next step is fixing the tests.

show more ...

attempt to model the JSON-RPC API as openapi spec

Failed because positional parameters are not really possible to model.
Named parameter could be introduces when our minimum requirement is
switched

attempt to model the JSON-RPC API as openapi spec

Failed because positional parameters are not really possible to model.
Named parameter could be introduces when our minimum requirement is
switched to PHP8+

show more ...

�� Rector and PHPCS fixes

JSON-RPC: we do not support named parameters

Even though this would be valid in JSON-RPC 2.0 we don't support it
currently. This adds the proper error handling for that.

JSON-RPC: throw proper error on invalid JSON

implement support for JSON-RPC 1.0, 1.1 and 2.0

This implements the slightly more standardized JSON-RPC standard as an
alternative to my home-grown version. The same server handled all formats
inclu

implement support for JSON-RPC 1.0, 1.1 and 2.0

This implements the slightly more standardized JSON-RPC standard as an
alternative to my home-grown version. The same server handled all formats
including my own simpler variant.

show more ...

�� Rector and PHPCS fixes

handle JSON encode/decode errors in JSONRPC API

Use str_starts_with/str_ends_with

�� Rector and PHPCS fixes

use $auth instanceof AuthPlugin instead of not null check

code style: line breaks

update some plugin classes in phpdocs, reformatting

recover comments in list

codestyle adjustments: function declaration braces/spaces

apply PSR-12 constant visibility rule

PSR-12 says constants need their visibility declared from PHP 7.1
onwards

relax instance check in remoteAPI loading

This broke tests. Ideally an Interface should be defined that both the
real APICore and the TestPlugin implement.

Apply rector fixes to inc/Remote

check XMLRPC mime type case-insensitive