disable bcc_self by default

[r10s]

this pr changes the default value for bcc_self to disabled for new installations. for existing existing installations, the value is not changed.

moreover, this pr adds a device-message when an autocrypt-setup-messages was decrypted successfully and bcc_self is disabled. the device-message informs the user about the bcc_self then. this is done in maybe_add_bcc_self_device_msg()

we may also call maybe_add_bcc_self_device_msg() when we see an incoming message that is not moved by us; this would also detect changes done on key transfers. but afaik, these parts are subject to change anyway, so maybe we can postpone that a bit.

closes #733

[hpk42]

the python tests have some dependencies on bcc-self=true. i guess the tests need to be adapted by either setting that mode, or changing the test assertions.

[hpk42]

lgtm -- but what makes sure that the device message is not re-added on a second ac_setup?

[r10s]

lgtm -- but what makes sure that the device message is not re-added on a second ac_setup?

currently - nothing.
but i think this is no big issue for asm. they are normally not sent all the time.

but in general, as we definitely need this feature for other device-messages, i'd add an optional unique-string-id to dc_add_device_msg(). dc_add_device_msg() would use the message-id <unique-string-id>@device - and if a message with that message-id already exist, nothing would happen. re-using the message id has the advantage that no special db-rows are needed and functions for searching etc. already exists. also the message-id is displayed in the info-dialog, which can also be of some worth for debugging purposes.

EDIT: thinking it over, it is probably better to not use the same namespace as for message-ids. otherwise an attacker could at least prevent device-messages popping up.