Fix fabric8:push goal in auto mode

[rohanKanojia]

fabric8:push goal seems to be failing due to no docker deamon
initialization being done. The cause seemed to be function isDockerAccessRequired()
which was ignoring the fact that docker access is also used in openshift mode. If we
don't specify any mode explicitly it is set to RuntimeMode.auto.

I think we should disable docker access check only when JIB=true

[rohanKanojia]

@toschder : I've created this PR for your issue. Could you please check if it's working for you?

[manusa]

According to the PR description, this has nothing to do with the issue.

Why can't we leave the call to super.excuteInternal(hub)?

[rohanKanojia]

Actually I did this to resolve docker.push.registry, super.executeInternal(hub) delegates to dmp's PushMojo where pushRegistry is null, we can make it protected in dmp but we would be blocked on updating dmp to new version.

If you want I can revert to previous state too

[manusa]

Ok, I see the problem now.

The value for the property docker.push.registry aliased as pushRegistry is required in JIB and variable must be "overridden">overwritten 🤢

There's an alternative to this (which is not ideal either) but that can be used to at least reuse some of the code (It's pointless to extend io.fabric8.maven.docker.PushMojo when we're not reusing anything at all).

The alternative is to define an extra variable with a different name and set the @Parameter annotation to pick up the values accordingly.
e.g.

    @Parameter(alias = "pushRegistry", property = "docker.push.registry")
    private String fabric8PushRegistry;

This way, the value of the parameter will be available through the whole class hierarchy (in this case FMP's PushMojo and DMP's PushMojo) without the need to redefine access privileges in parent classes. (Check marcnuri-forks@86d60b8 to see the changes)

For the current case, given that we're not using anything from the parent PushMojo (DMP) I would change the class to extend from AbstractDockerMojo.

But it's really important that you keep in mind the above procedure when you require an inaccessible parameter from a parent class, as overwriting them will lead to bugs.