Restrict members access to critical tables

[jumaffre]

Follow up from: #797 (comment)

Flexible governance allows members to perform a virtually-unlimited set of operations on the white-listed tables in the KV. And even if we provide a sensible default white-list, the constitution may allow this white-list to be updated (e.g. via unanimity of members).

This causes issues in terms of:

• Security. For example, it might be possible that members write a new node to the KV, bypassing the attestation and code version verification performed during the join protocol.
• Usability. Members may decide to add a new user but only update the ccf.users table. However, the ccf.user_certs and ccf.values tables should also be updated. (This particular point may be addressed by providing a richer KV API.)

This should be addressed by (at least) documenting these restrictions.

[achamayou]

I think we should look at this from the perspective of preserving invariants, beyond Lua's type system abilities and beyond the KV's interface

[jumaffre]

Now that we issue new shares on consortium updates, etc., we should definitely make sure that members cannot raw_puts to the ccf.members table directly. Some unit and e2e tests still rely on this so I've left this table in the whitelist for now.

[achamayou]

@jumaffre yes, this is otherwise a serious issue!

[achamayou]

With governance proposals being restricted to pre-defined constitution functions, and a safe set of default actions, I don't think this is a problem anymore, since:

1. There is no raw_puts in our default actions
2. Multi-table actions have been simplified (thanks to new ids), and the default actions are a safe starting point for customisation if desired.
3. Unsafe actions would need to be voted in as constitution amendments before they can be used. This is equivalent in governance complexity to a code update, so I think we've effectively made as much of an improvement as possible.