mon: OSDMonitor: receive CephInt on 'osd pool set' instead on CephString

This partially reverts 2fe0d0d9 in order to allow Emperor monitors to
forward mon command messages to Dumpling monitors without breaking a
cluster.

The need for this patch became obvious after issue #6796 was triggered.
Basically, in a mixed cluster of Emperor/Dumpling monitors, if a client
happens to obtain the command descriptions from an Emperor monitor and
then issue an 'osd pool set' this can turn out in one of two ways:

1. client msg gets forwarded to an Emperor leader and everything's a-okay;
2. client msg gets forwarded to a Dumpling leader and the string fails to
be interpreted without the monitor noticing, thus leaving the monitor with
an uninitialized variable leading to trouble.

If 2 is triggered, a multitude of bad things can happen, such as thousands
of pg splits, due to a simple 'osd set pool foo pg_num 128' turning out
to be interpreted as 109120394 or some other random number.

This patch is such that we make sure the client sends an integer instead
of a string. We also make sure to interpret anything the client sends as
possibly being a string, or an integer.

Fixes: 6796

Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
mon: OSDMonitor: don't crash if formatter is invalid during osd crush dump

Code would assume a formatter would always be defined. If a 'plain'
formatter or even an invalid formatter were to be supplied, the monitor
would crash and burn in poor style.

Fixes: 6820

Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
doc: rados: operations: pools: document 'osd pool set foo hashpspool'

Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
PendingReleaseNotes: mention 6796 and 'ceph osd pool set' behavior change

Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>