First impression after reviewing the current API

[Jens Schauder]

Hi,
great to see that this API moves forward and gets developed in the open.

I went through the Async JDBC API and tried to understand how it might get
used. Especially with regards to the Flow integration.
I have a hard time understanding how that integration is supposed to work.
Let's start with some details:

- `OperationGroup` has various methods to create `Operation`s that each
takes a SQL String as an argument. There is `rowOperation` which returns a
`ParameterizedRowOperation`, which allows to set bind parameters and is
intended to produce `Row`s.
So I guess this would be the one to use for everyday SELECT statements.
But if I want to use an Operation as a `Publisher` I would need to call
`publisherOperation` but then I can't provide parameters.
Let alone parameters provided by one or more `Publisher`s

- `Result.Row` extends `Flow.Subscription` but a `Subscription` should be
the result of a `Subscriber` subscribing to a `Provider`.
Having many (one for each row) `Subscription`s that nobody subscribed for
seems strange and confusing.
It also seems to redefine the specification of `Subscription` by allowing
implementations to ignore calls to `request`.


Overall I have the impression that multiple separate things are getting
crammed into the `Operation` inheritance hierarchy:
- How to specify the SQL statement to be executed (via
`ParameterizedRowOperation`)
- How to consume the results (via `PublisherOperation`)
- How to aggregate results (via `RowOperation.rowAggregator`)

Part of the reason for this might be that the API is partially based on
`Future`s and partially on `Flow`s.
I think one might arrive at a cleaner API if one goes all out for one of
the approaches, and leaves the conversion between the worlds to other APIs.


Some other minor things I noted/do not understand:

- Operation.timeout throws an exception when called more than once. Why not
just use the last value? This behavior makes cascading configuration
unnecessarily difficult, where one part of the code receives an
`Operation`, without being informed about if there was already a timeout
set.
- what is a SQL format mentioned in `DataSource.translateSql` and
`supportedTranslateSqlFormats`?
- What does public <T> T ResultMap.get(String id, Class<T> type); return if
the value identified by id cannot be converted to the type indicated by
type?
- The complete lack of metadata seems to be problematic. How does one
obtain data in a usable generic way if nothing of it's type can be known?
One might pass in Object.class but the return type is then completely
becomes vendor specific, and might be some internal representation. I think
some minimal metadata like the preferred/the available types either as Java
types or as SqlTypes should be available.
- public OperationGroup<S, T> memberAggregator(BiFunction<T, S, T>
aggregator); Forces an `OperationGroup` to keep all results of all
contained `Operation`s until this method is called or the the group is
completed.
Maybe it should throw an exception if it gets called after the first
Operation is submitted?

Kind regards
Jens Schauder