feat: add a DynamoDBContextBuilder to construct a DynamoDBContext

[philasmar]

To build the low level DynamoDB requests from both high-level programming models, the SDK requires knowledge of the table and index key structure. It generally relies on an internal call to DescribeTable. This call may invoked from synchronous public APIs, which relies on the sync-over-async antipattern for versions of .NET that only have an async HTTP client. This can lead to performance issues and deadlocks.

In October 2023 we released new initializers for users to provide the table and index structure on the client and skip the DescribeTable call.

• Design: https://quip-amazon.com/H6OSA2nu5EQx/DynamoDB-Threadpool-Deadlock-Current-Library
• Launch blog post: https://aws.amazon.com/blogs/developer/improved-dynamodb-initialization-patterns-for-the-aws-sdk-for-net/

Description

The aim of this PR is to mark the methods that reply on sync-over-async calls as [Obsolete] in order to encourage users to use the new TableBuilder for the Document model, as well as the new DynamoDBContextBuilder, which is introduced in this PR, for the object-persistence model.

For the document model, this PR obsoletes all the LoadTable and TryLoadTable calls.
For the object-persistence model, this PR adds a new DynamoDBContextBuilder which constructs a DynamoDBContext that sets DisableFetchingTableMetadata to true by default.

Motivation and Context

This change is required to mode customers away from sync-over-async calls which have lead to performance issues and deadlocks in the past.

Testing

For testing, I have added new tests that use the new DynamoDBContextBuilder to create the DynamoDBContext and I left some tests that create the DynamoDBContext using the old way.
I have ran all the tests locally and they have passed.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My code follows the code style of this project
• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have read the README document
• I have added tests to cover my changes
• All new and existing tests passed

License

• I confirm that this pull request can be released under the Apache 2 license

[eddiemcs3]

I would like to see unit test coverage for the different methods that build the context based upon a provided client, region, and configuration. Are these somewhere that I missed?

[philasmar]

I would like to see unit test coverage for the different methods that build the context based upon a provided client, region, and configuration. Are these somewhere that I missed?

The constructed DynamoDBContext does not expose any of the underlying objects that were configured by the builder, so there's nothing for me to assert on. There is a unit test that asserts an exception is thrown when 2 methods are called together, but that is the extent of it.

[normj]

Add would suggest giving more context for users upgrading about how this newer approach disables the DescribeTable mechanism. And explain how the can use the ConfigureContext method to revert to pervious behavior if they need it.

[philasmar]

Added more docs in the interface and inheritor.

[normj]

Add a line that says alternatively to attributes on the class you can register the table definition using the RegisterTableDefinition method on the context object.

[philasmar]

Done

[normj]

Add a line that says alternatively to attributes on the class you can register the table definition using the RegisterTableDefinition method on the context object.

[normj]

Do you want to use <inheritdoc/> instead of duplicating this large comment block?

[philasmar]

Done

[philasmar]

I rebased on top of v4-development. I'll run a dry run and merge if it succeeds.