librbd: make diff-iterate in fast-diff mode aware of encryption

librbd: make diff-iterate in fast-diff mode aware of encryption

diff-iterate wasn't updated when librbd was being prepared to support
encryption in commit 8d6a47933269 ("librbd: add crypto image dispatch
layer").  This is even noted in [1]:

> The two places I skipped for now are DiffIterate and TrimRequest.

CryptoImageDispatch has since been removed, but diff-iterate in
fast-diff mode is still unaware of encryption and just assumes that all
offsets are raw.  This means that the callback gets invoked with
incorrect image offsets when encryption is loaded.  For example, for
a LUKS1-formatted image with some data at offsets 0 and 20971520,
diff-iterate with encryption loaded reports

  0~4194304
  4194304~4194304
  25165824~4194304

instead of

  0~4194304
  20971520~4194304

as "exists".  For any piece of code that is using diff-iterate to
optimize block-by-block processing (e.g. copy an encrypted source image
to a differently-encrypted destination image), this is fatal: it would
skip processing block 20971520 which has data and instead process block
25165824 which doesn't have any data and was to be skipped, producing
a corrupted destination image.

[1] https://github.com/ceph/ceph/pull/37935#issue-735278403

Fixes: https://tracker.ceph.com/issues/66570
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit cdeb0efce3f9f857ad6d5b7ff3965f3292cb571a)

Conflicts:
	src/librbd/api/DiffIterate.cc [ ImageArea support not in
	  quincy ]
	src/test/librbd/test_librbd.cc [ commit 4a5a0a5dd82b ("librbd:
	  add cloned images encryption API") not in quincy