Also fix up some return values and stuff to use bool (or void if
nothing). I just did it whilst I was here.
According to jilles, the return value used to signify whether or not the
client had exited. This was error-prone and was fixed a long, long time
ago, but the return value was left int for historical reasons.
Since the return type is not used (and has no clear use case anyway),
it's safe to just get rid of it.
While what chanroles are trying to accomplish is a good idea, it is
apparently unclear this is the proper way to do it. Until we figure out
the exact way we wish to do this, it should be reverted for now.
As jilles pointed out, it is best that the chanserv access list always
remain synced with the grant list. Thus, the ability for clients to set
this is not a good idea unless services knows about the grant, but this
leads to all sorts of messy issues and likely isn't worth it.
this makes setting new roles on a user much easier as we're just setting the roles they
should be having, instead of having to try to revoke roles we don't necessarily know
about.
The theory behind this is that services sends an ENCAP * GRANT #channel
UID :+flagspec message specifying the chanroles the user has. They are
mapped into flag bits and applied to the membership of the user. They
then are restricted or permitted to what they can do based on the
permissions mask regardless of rank.
For backwards compatibility, the default permission bit (without a GRANT
statement) allows a user to to anything an existing op can do ONLY if
they are an op.
Todo: make CHANROLE_STATUS work (the ability to apply +ov to people),
which is at the moment controlled by CHANROLE_MODE.
