User keychains preparation for a higher value cypher

Dear Suranga,

Thank you for the proposal.
Here are some comments:

1. There is no such thing as a default cipher. However, our latest release has a default option for `proc-rsa-key-size` ("RSA keys size" in global settings at `admin/config/system/proc`). We could indeed move that up to 4098. But this is a less effective measure, for the purpose of strengthening secrecy, than forcing a bigger symmetric encryption passphrase at the moment of keyring creation. New implementations, not dealing with the import of old keys, should indeed opt for 4098 allowing new key holders to create their keys already at the bigger size.
2. In general, out of the scope of transitioning from one key to another, we do not want to allow multiple keyrings. In fact, the concept of a keychain does not exist in the PGP standard. We can indeed come up with a solution for optimising downtime at the moment encryption update is at stake. There is a plan for having this running with a web worker and there is a possibility that such a solution for allowing multiple keyrings to be used by the same user at the same time will not be needed.
3. The proposal of splitting keyrings from ciphers is good, but not necessarily needed. Sometimes we want a smaller amount of moving parts in the machine. Both types of proc entities have an armoured representation in common, and this is enough similarity to make them to be kept together.
4. We do need services all around, or at least hook implementations, to make proc better controllable from other modules. I would really appreciate a code proposal in this direction. This might be important mainly for the control of the recipient's fetcher endpoint per form display or form mode. This way, changes to the fetcher of recipients can be performed without bringing up the burden to the form where the field is placed.
5. The idea of a js/proc-api.js is interesting. You mention: "Sometimes the encryption requires some backend process to have already been run. For example a form where the recipients are no longer in a form element". This is indeed the case, mainly at the single page (not in a multistep form) private message context. However, proc tries not to be opinionated and this is something to be done at the side of the implementing application. Proc tries to focus on encryption operations, and leaves UX adjustments to the side of the application. Please refer to item 4. Despite having a TO and CC settings for the direct fetcher, we do not want to mention private message anywhere else in proc, once it is intended to be used under standalone mode or via any fieldable form.
6. Still talking about the concept of multiple keyrings, because you also mention it at ProcStorageHandler class, we do not really have "disabled keyrings" once only the most recent one is used. Again, in the context of re-encryption we might want to make use of the immediate previous key, but this is a special scenario to be tackled together with a more mature re-encryption solution.
7. At ProcStorageHandler you mention "insufficiently strong ciphers". From the point of view of proc there is no such thing. This is something to be decided at the application side. Proc tries not to be opinionated in general and especially in regard to this.
8. Thank you for mentioning phpstan violations and typos. You will be mentioned on the commits fixing those.
9. Thank you also for the proposal of a AbstractEncryptionForm class.
10. Proc tries to subscribe to modularity and reusability. So far, stand alone operations are being reused for handling field mode and therefore a EncryptFileModalForm is not needed. If this comes to be changed it will be in favor of a full "inline" operation, as you have also mentioned in your comments. It is not a priority so far as long as we are able to reuse the standalone mode via dialog.

Next time please try to restrict the scope you change request. This way it will be faster to review.

Thank you very much again!