5.x - undocumented wildcard behaviour change in `req.params`

[krzysdz]

Description

Anthony Moulen pointed out on Slack a change in req.params behaviour when using wildcards. Since path-to-regexp@7 wildcards split the matched path on /.

route 4.x	route 5.x	request path	req.params 4.x	req.params 5.x
'/:name'	'/:name'	/a%2fb	{ name: 'a/b' }	{ name: 'a/b' }
'/*'	'/*name'	/	{ '0': '' }	not matched
'/*'	'/{*name}'	/	{ '0': '' }	{}
'/*'	'/*name'	/a%2fb/c	{ '0': 'a/b/c' }	{ name: [ 'a/b', 'c' ] }
'/*'	'/*name'	/a%2fb	{ '0': 'a/b' }	{ name: [ 'a/b' ] }

The migration guide describes the changes in path matching - that wildcard parameters now must be named and that {} is required to make the path segment optional. What it does not described is that:

1. Wildcard parameters in req.params are always represented as arrays of decoded segments, not a single string.
2. (less important) Optional wildcard segment that is not matched does not exist in req.params, while in 4.x it was an empty string.
3. (not important) req.params object in 5.x has null prototype.

Expectations

Migration guide should mention different req.params behaviour with regard to wildcard parameters.

This probably can be combined with req.params documentation improvements requested in #1891.