Improve behavior when editing encrypted devices

[ancorgs]

Problem

Editing a block device that already contains an encryption layer has some problems, described at
https://trello.com/c/qeSZSCxQ/1244-5-partitioner-fix-behavior-when-selecting-deselecting-encryption-checkbox

This PR specifically targets the following problems:

• If the password was already provided, editing again looses it and asks for a new password. That will become a bigger problem soon, since we plan to add more types of encryption (random, pervasive, maybe LUKS2) each of them with their own arguments. Having to re-enter the type and all the arguments would be even a better PITA than it's today.
• If there is already a existing encryption in the system (e.g. a LUKS2 one created with other tool), it cannot be reused. This will also become a bigger problem soon with pervasive encryption, in which likely the user doesn't want to re-encrypt the device, but simply use the existing one and (re)format the resulting device.

Solution

When encrypting for the first time a device that was not originally encrypted in the system (or encrypting a new device just created using the Partitioner), nothing changes apart from minor adjustments in the labels. The user simply sees a form with an empty "password" field.

When editing for a second time a device that was already marked for encryption during the current execution of the Partitioner, the form is already prefilled with the password entered before. In the past, the previous encryption layered was ditched (so it's password and other arguments were forgotten) and the user had to define the encryption again from scratch. That will become even more relevant soon, when the form for encryption becomes more than just a "password" field. See #960.

Last but not least, when editing a device that is already encrypted in the system (that is, it contains an active encryption layer that was there already when the Partitioner was executed), an option is offered to just use the existing encryption layer instead of replacing it with a (likely more limited) encryption created by the Partitioner.

Note the option is only possible if the preexisting encryption device is active (e.g. the user already entered its passphrase during boot or during the initial hardware probing performed by the Partitioner).

Testing

• Unit test coverage extended
• Tested manually with the partitioner_testing client
• Not done yet: manually test a full installation with reused encryption

[coveralls]

Coverage increased (+0.01%) to 97.636% when pulling ded61e0 on ancorgs:refactor_encrypt into 9f359f2 on yast:master.

[dgdavid]

Although the PR is in draft yet, I left there two minor comments.

[dgdavid]

Despite my two nitpickings, LGTM 👍

[yast-bot]

✔️ Public Jenkins job #203 successfully finished
✔️ Created OBS submit request #728551

[yast-bot]

✔️ Internal Jenkins job #28 successfully finished
✔️ Created IBS submit request #200273