Consider adding string overloads of DbDataReader.GetFieldValueAsync and DbDataReader.IsDBNullAsync

[divega]

When we reviewed the API for #27059 we decided to leave async methods for later, for various reasons:

• It is less commonly used API (only required for sequential access)
• We were hoping to come up with some new API pattern for handling nullability that takes advantage of the new support for nullable reference types in C#
• We had doubts on whether new fine-grained async API should return ValueTask<T> instead of Task<T>

However, given that we haven't made progress towards a new API pattern for nullability, and that this async API isn't that commonly used, it seems to me that adding the corresponding string versions for the two existing async methods is the simplest way to complete the improvement we started in #27059.

Proposed API:

 public abstract class DbDataReader
 {
    public Task<T> GetFieldValueAsync<T>(string name) => GetFieldValueAsync(GetOrdinal(name));
    public Task<bool> IsDBNullAsync(string name) => IsDBNullAsync(GetOrdinal(name));
}

cc @roji @ajcvickers

[roji]

I think the idea was to give a bit more time to see what happens with dotnet/csharplang#2194 (for nullability). Aside from that it definitely seems wise to have column-access methods return ValueTask rather than Task - although in this specific case it would make the API inconsistent (ordinal overload returns Task, string overload returns ValueTask).

Another way to look at this would be to add these two overloads now, at the very least for API consistently (why are they missing whereas all the others are there). Later, when we have a clear answer on the nullability issue we can add new methods (with new names) which would return ValueTask. This path wouldn't add any additional clutter as the ordinal overloads which return Task are already there...

[divega]

@roji Also, if we are having ValueTask<T> returning versions of these, then the version that is virtual and takes the ordinal int needs to exist first. If we do something with nullabilily, that that is also a cross-cutting concern that is going to affect all sync and async versions, as well as string and int flavors of the methods.

So yes, I only created this issue for the short term goal of making things a bit more consistent, which seems to be low hanging fruit.

[roji]

Closing in favor of #27059 which includes this now.