… tiny bit

Should not change behavior.

Signed-off-by: Miloslav Trmač <mitr@redhat.com>

…s.go

Let's try to make copy.go shorter, and consolidate progress bar code to
new copy/progress_bars.go.

First, move the code from copy.go.

Only moves unchanged code, should not change behavior.

Signed-off-by: Miloslav Trmač <mitr@redhat.com>

Second part: Move blobChunkAccessorProxy to the newly established
progress_bars.go.

Only moves unchanged code, should not change behavior.

Signed-off-by: Miloslav Trmač <mitr@redhat.com>

... to cleanly differentiate the code related to chan<- types.ProgressProperties
from the code related to progress bars.

Only moves unchanged code, should not change behavior.

Signed-off-by: Miloslav Trmač <mitr@redhat.com>

The same srcInfo.size was passed to createProgressBar, so this
does nothing at best if size is known; if it is unknown,
it seems to effectively also be a no-op with a recent version of mpb
(it sets the total value to 0, the current progress at the time,
but it doesn't enable auto-complete, so it doesn't make a difference).

Signed-off-by: Miloslav Trmač <mitr@redhat.com>

Already draw the progress bar before opening the source's layer
or config blob, so that the users can have a visual indication
of something related to that blob happening if it takes too long.

(For the .ConfigBlob() call, this might not make a difference,
because in _some_ cases we trigger reading the config via
.OCIConfig in checkImageDestinationForCurrentRuntime(), and the
config blob is cached, but it might make a difference in the other
cases, and it doesn't hurt in this one.)

Signed-off-by: Miloslav Trmač <mitr@redhat.com>

In particular, if the source is compressed, track the full size
of the original compressed blob in the progress bar, even if the decompressed
version has a different size (e.g. because the encryption adds a header or a MAC).

This original size is easy to determine and eaiser to explain to users; so let's do
the simple thing.

Signed-off-by: Miloslav Trmač <mitr@redhat.com>

This will allow us to add more state and methods to the bar
object, without copy&pasting.

For now, this just wraps one pointer in another, and should
not change behavior.

Signed-off-by: Miloslav Trmač <mitr@redhat.com>

This correctly handles both the "size known" and the "size unknown" cases,
and because we now record the originally-configured progress bar size
in the progressBar struct, the caller doesn't need to track it.

Signed-off-by: Miloslav Trmač <mitr@redhat.com>

If srcInfo.Size == -1, the progress bar is not showing the
refill value anyway (customPartialBlobDecorFunc is only
used if size is known), so don't bother calling this function
with nonsense data, if anything, at least to emphasize that this
condition is, in principle, possible.

Should not affect behavior, hopefully.

Signed-off-by: Miloslav Trmač <mitr@redhat.com>

... so that we test all of this with the new semantics.

Signed-off-by: Miloslav Trmač <mitr@redhat.com>