Change: make malicious zip file checks a synchronous PublishCheck

[netomi]

This fixes #1718 .

Currently, malicious zip checks where done asynchronously during publishing, meaning that if a new extension is rejected because of that, the user does not have immediate feedback.

Now if scanning is enabled, the check will be done synchronously and reject the publication and inform the publisher instead of creating an extension version and not activating it.

Furthermore, if scanning is not enabled, the behavior stays the same as before, meaning the malicious zip check is done asynchronously, but the potentially_malicious flag will be correctly set now.

[autumnfound]

suggestion (non-blocking): It might be worth adding a few basic unit tests in for the newly moved zip check. I think the scanService being disabled is a fairly niche edge case for the handler, though having a test there wouldn't hurt either.

[netomi]

Having a test for the PublishExtensionVersionHandler in case no scanning service is enabled would be worthwhile but for now is just an overkill. It did not exist so far and will not be actively used anymore. Imho, the malicious check should be removed at some point in time from this code path and be made fully configurable when scanning service is enabled. So when no scanning is enabled, all extensions pass through, useful for testing or development instances not advised for anything serious though.

I created #1723 to support some extra fields as right now we just reject publication if any extra field is encountered, which is a bit strict.