xapi-idl: Add xcp-rrdd methods for Protocol V3

[TSnake41]

Add Plugin.Metrics.register, Plugin.Metrics.deregister and Plugin.Metrics.get_versions RPC methods to xapi-idl.

Plugin.Metrics.register:
Register a protocol v3 plugin (as defined in xapi-project/xapi-project.github.io#278) to xcp-rrdd daemon (or a compatible implementation) using a uid (that is similar to Plugin.Local.register uid) and a specific OpenMetrics version to use in protocol v3 payload (e.g "OpenMetrics 1.0.0").
If the xcp-rrdd daemon doesn't support the asked OpenMetrics version, this method is supposed to fail (see Plugin.Metrics.get_versions).

Plugin.Metrics.deregister:
Basically the same as Plugin.Local.deregister, added for consistency.

Plugin.Metrics.get_versions:
Get the list of OpenMetrics versions supported by the xcp-rrdd daemon that can be used for Plugin.Metrics.register.

Ideally, a plugin should call Plugin.Metrics.get_versions first to get the list of supported OpenMetrics versions, and choose one that the plugin supports, or fail otherwise.

Open questions/issues :

• I haven't found out how to specify a list/array as a RPC parameter in OCaml, which causes syntax issues with get_versions versions_p parameter.
• Should OpenMetrics versions be handled as precise versions (e.g OpenMetrics 1.0.0) or follow semantic versioning and consider non-breaking changes as the same version (use e.g OpenMetrics 1.0 for 1.0.0, 1.0.1 and so on) ?
• Should Plugin.Metrics.register be always deregistered using Plugin.Metrics.deregister to allow more easily separating protocol v2 code with v3 code ?

[psafont]

The think the new functions should be made more general, they should include the version of the plugin protocol used, and some identifying information, e.g. like the path of the file that the metrics daemons needs to read.

A variant type would be useful for that:

type test_variant_name =
  | VTwo of string (** Filepath *)
  | VThree of string * string (** Filepath, openmetrics version*)
[@@deriving rpcty]

Aside from that, the PR needs to add at least dummy functions to implement the two new methods, or it will crash at runtime. They can have proper implementations added later on, however.

[robhoes]

There is already a protocol version type on the top of the file:

(** Version 1 or 2 of plugin protocol *)
type plugin_protocol =
  | V1  (** Plugin protocol 1 *)
  | V2  (** Plugin protocol 2 *)
[@@default V2] [@@deriving rpcty]

This is used in the protocol_p parameter in Plugin.Local.register. Why wouldn't we extend this rather than adding parallel register/deregister functions?

[TSnake41]

There is already a protocol version type on the top of the file:

(** Version 1 or 2 of plugin protocol *)
type plugin_protocol =
  | V1  (** Plugin protocol 1 *)
  | V2  (** Plugin protocol 2 *)
[@@default V2] [@@deriving rpcty]

This is used in the protocol_p parameter in Plugin.Local.register. Why wouldn't we extend this rather than adding parallel register/deregister functions?

The Plugin.Metrics.register was added to allow negociation of the OpenMetrics version (specified by version on this RPC method). I haven't considered extending the current interface for this though (was considering that it may break the RPC API). If it doesn't cause issues to allow an optional field for "Plugin.Local.register" (something like sub_version), I am perfectly ok with it.

[psafont]

it should be able to add a parameter to V3, like so:

(** Version 1 or 2 of plugin protocol *)
type plugin_protocol =
  | V1  (** Plugin protocol 1 *)
  | V2  (** Plugin protocol 2 *)
  | V3 of string (** Plugin protocol 3 with openmetrics version *)
[@@default V2] [@@deriving rpcty]