osd: introduce HASHPSPOOL pool flag, feature to avoid overlapping pg placements

The existing code will overlay the placement of PGs from pools because
it simply adds the ps to the pool as the CRUSH input.  That means that
the layout/placement for pg 0.10 == 1.9 == 2.8 == 3.7 == 4.6 == ...,
which is not optimal.

Instead, use hash(ps, poolid).  The avoids the initial problem of
the sequence being adjacent to other pools.  It also avoids the (small)
possibility that hash(poolid) will drop us somewhere in the output
number space where our sequence of outputs overlaps with some other
pool; instead, out output sequence will be a fully random (for a well-
behaved hash).

Use the multi-input hash functions used by CRUSH for this.

Default to the legacy behavior for now.  We won't enable this until
deployed systems and kernel code catch up.

Fixes: #4128
Signed-off-by: Sage Weil <sage@inktank.com>
mon: move OSDMap feature bit calculation into an OSDMap method

Signed-off-by: Sage Weil <sage@inktank.com>
osd/OSDMap: note OSDHASHPSPOOL feature when pool FLAG_HASHPSPOOL is set

This allows the osd and mon to enforce feature bits on their connections.

Signed-off-by: Sage Weil <sage@inktank.com>