follow-up issues for metadata

Tracking follow-ups from #2273:

persistence for user metadata (depends on account refactor
before-connect
enforce max-value-length
Upon requesting the metadata capability, clients receive their non-transient metadata (for example, metadata stored by the server or by services) in a metadata batch with their own nick as target. If none exists, the server MUST send an empty batch instead.
consider rate-limiting for user metadata changes (channels aren't really a concern, since relaying channel updates is cheaper than an ordinary PRIVMSG)
if enforce-utf8 is disabled we need to check values for UTF8 compliance
figure out key count limit for channels
When subscribing to a key, clients SHOULD receive the current value of that key for channels/users they are receiving updates for.
Clients SHOULD receive the current values of keys they are subscribed to when they MONITOR a user, or when one of their monitored users comes online.
Add a metadata allowance to fakelag.command-budgets
RPL_WHOISKEYVALUE
target as an additional argument to the metadata batch?

Provide feedback