attempt NRT makeover

[mgravell]

Functionally, the only real changes here are in a few API surfaces (not a real change, but NRT changes things slightly):

NOTE: the intention is to do a minor rev here, i.e. ship this as 2.1.0

• type handlers take and return ?
• {Query|Read}{First|Single}OrDefault[Async] return ?
• ExecuteScalar[Async] return ?
• update libs
• package readme.md (this is the current NuGet recommendation)
• enable [SkipLocalsInit] everywhere; simplify the remoting warning logic

for Dapper.AOT purposes (although everything here applies to any consumer), I'm also applying some tweaks to make GridReader more usable from externals; GridReader is not sealed, but was mostly unusable from custom implementations - added some things:

• protected constructor
• switched to Action<object?>?/object? callback rather than type-specific (so external consumers aren't bound to same types)
• added protected int OnBeforeGrid() (pre-grid book-keeping)
• added protected void OnAfterGrid(int) and protected Task OnAfterGridAsync(int) (post-grid book-keeping)
• made all existing usage consistently use that OnBeforeGrid/OnAfterGrid API
• exposed the reader and cancellation-token via protected APIs
• allow the Identity to be constructed on-the-fly if/when needed

(the NRT issue was also partly driven from AOT)

[mgravell]

@NickCraver I've added API proof to this; do you have an opinion on this? otherwise, ima merge

[NickCraver]

@mgravell I can this afternoon or tonight - but if not doing a release and this is blocking, happy to comment after the merge too and we can tidy to parallel - your call!

[mgravell]

Not immediately blocking; however it is a pain to have to keep rebasing it (which is why it is heavily squashed and force-pushed), as it touches a lot

[NickCraver]

@mgravell Tried to give good eyes here, admittedly glossed over the NRT exclusions in the Emit section as the last reviewed thing, I'll review it fresh next round (just a lot to consume in one go - nothing wrong on PR structure)

[mgravell]

addressed all, I think

[jnm2]

@mgravell Since this causes implementers of the class to have to annotate their T value parameter as nullable, how would we handle null being passed here? What would it mean?

I know for SqlParameter.Value, DBNull means "set to null" and null means "unset." Does null carry the same "unset" connotation if implementers see it here?

Thanks!

[mgravell]

Since there isn't a constraint on T, this doesn't strictly change the API shape - in particular, a TypeHandler<SomeValueType> still has SetValue(..., SomeValueType) and not SetValue(..., SomeValueType?) ; however, to answer your question: it should mean DBNull, but with the opportunity to configure the parameter correctly, and mostly just applies in the TypeHandler<SomeReferenceType> scenario, it acknowledges that the incoming parameter might benull.