Provide way to get image size without using extents

[ahadas]

The http backed need to know the image size for validating requests to the
server. Since we did not have a way to get the size from the server, we
implemented size() using extents request, and cached the extents for future
calls.

Using extents to get the size is inefficient, and may take lot of time on
large images on fragmented file systems.

Add the image size the OPTIONS response:

Example request:

OPTIONS /images/tiket-id

Return json with:

{
   "features": ["flush", "zero", "extents"],
   "unix_socket": "...",
   "max_readers": 8,
   "max_writers": 8,
   "size": 53687091200,
   ... 
}

The size should be the effective size that can downloaded or uploaded,
using the same logic used to validate range requests.

I think we need to add more info that can be helpful for the client, for
example:

• the minimum block size (we want aligned writes)
• the preferred request size (128m?)
• transfer id (used for debugging transfer flows)
• sparse (writing zero will deacllocate space)
• dirty (dirty extents available, only during backup)

This maps nicely to the NBD protocol handshake, reporting all he info about
the remote disk.

The http backend should be updated to use the size reported in OPTIONS
instead of doing a slow extent request to get the size.

Original bug: https://bugzilla.redhat.com/1924945

[nirs]

This is also helps to avoid disconnection of idle connections (#71) if a client is using multiple connections and is waiting util the initial EXTENTS request completes.

In imageio client this does not happen since we send the first EXTENTS request before creating the other connections, as part of initial validation. But other clients may use different design and hit this issue.