Restrict JSON-RPC request/notification params to objects and arrays

[ebkalderon]

According to both the JSON-RPC 2.0 specification and the Language Server Protocol specification, the params field in all JSON-RPC requests and notifications must be either:

• by-position: params MUST be an Array, containing the values in the Server expected order.
• by-name: params MUST be an Object, with member names that match the Server expected parameter names. The absence of expected names MAY result in an error being generated. The names MUST match exactly, including case, to the method's expected parameters.

At the time of writing, tower-lsp's Request type does not reject messages with params fields that are not either object-like or array-like. This was done to accommodate the telemetry/event notification which, until recently, erroneously mandated a params type of object | number | boolean | string. Thankfully, this was corrected in the spec: microsoft/language-server-protocol#1686

We already restrict users from emitting non-object and non-array telemetry/event payloads in client.rs, so there's no additional work necessary on that front.

tower-lsp/src/service/client.rs

Lines 203 to 211 in e96d8ca

	match serde_json::to_value(data) {
	Err(e) => error!("invalid JSON in `telemetry/event` notification: {}", e),
	Ok(mut value) => {
	if !value.is_null() && !value.is_array() && !value.is_object() {
	value = Value::Array(vec![value]);
	}
	self.send_notification_unchecked::<TelemetryEvent>(value)
	.await;
	}

However, we should still update the Request type and LspServiceBuilder::custom_method() to reject params values that are not serializable/deserializable to and from objects/arrays in order to fully comply.

[ebkalderon]

I've opened gluon-lang/lsp-types#259 to correct this at the lsp-types level.

[ebkalderon]

This issue was previously touched on in PR #379. Most of the code in improve-jsonrpc-deserialization that hasn't yet been integrated into mainline covers a big portion of this work already.