Split connector code into streaming and batch

[SamoylovMD]

The current codebase is overloaded with conditionals, interconnected or ignored properties and doesn't take into account different limits of BigQuery API. That makes it harder to support and may lead to unobvious configuration problems.

The proposal is to split the current monolithic sink connector into separate artifacts, one for streaming via Storage Write API, another through GCS load jobs. It would make the code much easier to understand and support.

[Claudenw]

My understanding was that the Storage Write API was the direction we were going to take. Perhaps it makes more sense to start a V3 feature branch and work at removing the other GCS code.

Would this make sense?

[edit] I initially said V4 when I meant V3.

[SamoylovMD]

@Claudenw according to data ingestion pricing, Storage Write API costs money after 2Tb/month, while batch loading is always free. I think the users might want to have a control over that, or to minimize ingestion costs.

For example, I currently have something like Kappa architecture, with data for both streaming and batching purposes going through Kafka. The amount of records I want to pass through streaming part is relatively small, maybe 100Gb/month, while batching part can be very large, up to 30Tb/month, and I wouldn't want to use Storage Write API in both cases because of pricing difference. In batching case it still makes sense for me to use GCS load jobs.

[Claudenw]

see #93 for discussion of how to implement.