Add a setting so providers can process images when no commands are supplied.

[Pandorax100]

Prerequisites

• I have written a descriptive pull-request title
• I have verified that there are no overlapping pull-requests open
• I have verified that I am following matches the existing coding patterns and practice as demonstrated in the repository. These follow strict Stylecop rules 👮.
• I have provided test coverage for my change (where applicable)

Description

Addresses #77

This exposes a setting on individual providers to determine whether they should continue processing an image when no commands are supplied. This is important for remote providers - such as the AzureBlobStorageImageProvider - as they are unable to fall back on the static files middleware to serve images.

[claassistantio]

All committers have signed the CLA.

[JimBobSquarePants]

@Pandorax100 Thanks for this, much appreciated!

I think if we make a couple of minor changes this will be good to go.

[Pandorax100]

I completely agree. The interface has had the setter removed, and the setting has been changed to an enum.

[deanmarcussen]

This looks good.

My only caveat (just from working around this issue) is that when an image comes in with no commands and is supported as ProcessingBehaviour.All the image will still get loaded by ImageSharp and saved back out as a different stream/image.

So it just means that the image will always be mutated in some way (which has an impact on memory / performance)

It would be nice if when there are no commands the image wasn't mutated, but I leave that choice with @JimBobSquarePants

[JimBobSquarePants]

@deanmarcussen makes a valid point above

@Pandorax100 We're still fully loading and saving the image when there are no commands.
We still need to identify the format so when there are no commands we should use the Image.Identify(stream, out IImageFormat format) method to get the correct mimetype.

I'm happy to accept this as-is and do the work though. I'm currently updating the build process and changing the targets to sensible ones (Core 3.1, Core 2.1) so don't want to keep you waiting longer than you need to.

[Pandorax100]

Yeah, I see the problem

I've just had a little look and it doesn't seem like Image.Identify(stream, out IImageFormat format) is available with the version of ImageSharp referenced by this project. I see that there is Image.DetectFormat(inStream) but if you're in the process of updating the build process etc then I think it's probably best to accept this as is and we can come back to it at a later date. If that's alright with you?

[JimBobSquarePants]

Totally fine. Will get this merged ASAP.