Diagrams是一个云系统架构原型图制作库，它的诞生是为了在没有任何设计工具的情况下对新的系统架构进行原型设计。您还可以描述或可视化现有系统架构，Diagram as Code允许您跟踪任何版本控制系统中的架构图更改。相比于在 UI 上面对各种图标进行拖拽和调整，这种方式更符合我们程序员的使用习惯。
Encryption is currently applied in exactly one place, while wrapping the stream
of an upload request that carries an upload session with encryption metadata.
A writer that moves a blob straight into a storage policy therefore stores it
as it was, which is how a storage policy relocation ends up leaving plaintext
on a policy that has file encryption enabled.
Add RelocateBlob, which transfers the blob of an entity into another storage
policy and applies that policy's encryption setting on the way. A blob that is
already encrypted is transferred as ciphertext under its existing data key, so
relocation costs no crypto and cannot invalidate the key held by the entity. A
plaintext blob relocated into a policy with encryption enabled is encrypted
during the transfer under a freshly generated data key, which is returned for
the caller to persist onto the entity, along with an EncryptMetadata field on
RelocateEntityParameter to commit it with.
The encryption metadata is returned rather than persisted so that the plaintext
data key never has to be carried in a resumable task state, and it is stripped
from the returned value for the same reason.
Extract the stream wrapping into encryptUploadRequest so both writers share it,
and pass the request offset as the counter offset instead of a hardcoded zero.
That is a no-op today, since server side encryption only ever runs on a relayed
upload, which is forced into a single chunk starting at zero, but it keeps the
keystream aligned for any writer that starts at an offset.
Refs #3518
PLus123456
