Dependencies: resolve maven conflicts between core and bundle

[osulzhenko]

🔧 Type of changes

• new bid adapter
• bid adapter update
• new feature
• new analytics adapter
• new module
• module update
• bugfix
• documentation
• configuration
• dependency update
• tech debt (test coverage, refactorings, etc.)

✨ What's the context?

What's the context for the changes?

🧠 Rationale behind the change

Why did you choose to make these changes? Were there any trade-offs you had to consider?

🔎 New Bid Adapter Checklist

• verify email contact works
• NO fully dynamic hostnames
• geographic host parameters are NOT required
• direct use of HTTP is prohibited - implement an existing Bidder interface that will do all the job
• if the ORTB is just forwarded to the endpoint, use the generic adapter - define the new adapter as the alias of the generic adapter
• cover an adapter configuration with an integration test

🧪 Test plan

How do you know the changes are safe to ship to production?

🏎 Quality check

• Are your changes following our code style guidelines?
• Are there any breaking changes in your code?
• Does your test coverage exceed 90%?
• Are there any erroneous console logs, debuggers or leftover code in your changes?

[osulzhenko]

The google-cloud-storage dependency creates conflicts on Maven dependencies, causing a mismatch between the core and bundle versions in all builds. @EvgeniiMunin will this change be okay for you?

[EvgeniiMunin]

Excluding failureaccess should be ok if it resolves the conflict on maven build and does not break the GCS fetching

[Net-burst]

Please swap groupId and artifactId. There is an unspoken convention that groupId should go before artifactId.

[Net-burst]

And while we're at it, it might be worth bumping dependencies for this module. Google cloud is being updated quite frequently, and we're already several versions behind.