Create the IOSImageDataFetcher

components/image_fetcher/image_data_fetcher.h

Index: components/image_fetcher/image_data_fetcher.h
diff --git a/components/image_fetcher/image_data_fetcher.h b/components/image_fetcher/image_data_fetcher.h
index 92c5a5cf0dc233d7c004adc58387f336115361bf..e578ba0aa22136046784a1e3d7cc66b97374e4cf 100644
--- a/components/image_fetcher/image_data_fetcher.h
+++ b/components/image_fetcher/image_data_fetcher.h
@@ -26,7 +26,8 @@ namespace image_fetcher {
 class ImageDataFetcher : public net::URLFetcherDelegate {
  public:
   using ImageDataFetcherCallback =
-      base::Callback<void(const std::string& image_data)>;
+      base::Callback<void(const std::string& image_data,
+                          const net::URLFetcher* source)>;

[gambard, 2017/01/30 13:37:53]

As the URLFetcher should probably not be exposed, I can change it for: int
response_code, std::string mime_type.
What do you think?

[Marc Treib, 2017/01/31 09:13:01]

I still don't quite see why you need the response code?
mime_type makes more sense IMO, though I'm not convinced it's necessary - IIRC,
you can detect WebP from a header ("magic bytes") in the data.

[gambard, 2017/01/31 09:24:20]

I agree that I can detect the type from the first bytes. If we want to keep the
callback as simple as possible it is probably the best way.
The response code is needed by the favicon driver:
https://cs.chromium.org/chromium/src/components/favicon/core/favicon_driver_i...

[Marc Treib, 2017/01/31 09:54:39]

I'd prefer that; not only to keep the callback simple, but mainly because I
think it's more reliable.
IIRC, Markus has done that exact thing at some point.
And where is that used? It doesn't seem to be called anywhere in this CL...?

 
   using DataUseServiceName = data_use_measurement::DataUseUserData::ServiceName;