When setting up filtering and sorting with UseFiltering and UseSorting,
there are 3 different code paths that are traversed. Prior to
this change, all 3 of them required that a convention be registered otherwise
an exception would occur. However, for both filtering and sorting, only 1 of
the code paths actually needs a convention. The other two do not use the
convention at all.

This commit changes the filtering and sorting object field descriptor extensions
to attempt to get a convention only within the block of code that requires a
convention. By making this small change, the other two code paths that do not
require a convention will no longer encounter an exception. Instead, filtering
and sorting can be set up as expected.

This commit partially addresses ChilliCream#6983. We are able locally, with these changes
applied, to use filtering and sorting from a type module by calling the versions
of `UseFiltering` and `UseSorting` that take a type. Without the changes in this
commit, we get the "no convention registered" error.

This change does not close ChilliCream#6983 as it is still possible to encounter the "no
convention registered" exception and its suggested remedy of
"Call `AddFiltering()` on the schema builder" doesn't work.

From what we can see, and have detailed in ChilliCream#6983, no conventions registered with
the schema builder either directly or the defaults provided by `AddFiltering`
and `AddSorting` are available at the time that a type module is run.

The result of this commit is to allow the usage `UseFiltering` and `UseSorting`
with types created via a type module. The other option we are aware of is
detailed by @jimitndiaye in ChilliCream#6975.
Jimit routes around the convention problem by not using a convention at all
in his custom middleware. A close examination of `UseFilteringInternal` at
ChilliCream#6975 (reply in thread)
will show this lack of convention usage as key to his fix. Instead of going
the custom middleware route, we made these two small changes to Hot Chocolate.
We prefer this approach.

When setting up filtering and sorting with UseFiltering and UseSorting,
there are 3 different code paths that are traversed. Prior to
this change, all 3 of them required that a convention be registered otherwise
an exception would occur. However, for both filtering and sorting, only 1 of
the code paths actually needs a convention. The other two do not use the
convention at all.

This commit changes the filtering and sorting object field descriptor extensions
to attempt to get a convention only within the block of code that requires a
convention. By making this small change, the other two code paths that do not
require a convention will no longer encounter an exception. Instead, filtering
and sorting can be set up as expected.

This commit partially addresses ChilliCream#6983. We are able locally, with these changes
applied, to use filtering and sorting from a type module by calling the versions
of `UseFiltering` and `UseSorting` that take a type. Without the changes in this
commit, we get the "no convention registered" error.

This change does not close ChilliCream#6983 as it is still possible to encounter the "no
convention registered" exception and its suggested remedy of
"Call `AddFiltering()` on the schema builder" doesn't work.

From what we can see, and have detailed in ChilliCream#6983, no conventions registered with
the schema builder either directly or the defaults provided by `AddFiltering`
and `AddSorting` are available at the time that a type module is run.

The result of this commit is to allow the usage `UseFiltering` and `UseSorting`
with types created via a type module. The other option we are aware of is
detailed by @jimitndiaye in ChilliCream#6975.
Jimit routes around the convention problem by not using a convention at all
in his custom middleware. A close examination of `UseFilteringInternal` at
ChilliCream#6975 (reply in thread)
will show this lack of convention usage as key to his fix. Instead of going
the custom middleware route, we made these two small changes to Hot Chocolate.
We prefer this approach.

When setting up filtering and sorting with UseFiltering and UseSorting,
there are 3 different code paths that are traversed. Prior to
this change, all 3 of them required that a convention be registered otherwise
an exception would occur. However, for both filtering and sorting, only 1 of
the code paths actually needs a convention. The other two do not use the
convention at all.

This commit changes the filtering and sorting object field descriptor extensions
to attempt to get a convention only within the block of code that requires a
convention. By making this small change, the other two code paths that do not
require a convention will no longer encounter an exception. Instead, filtering
and sorting can be set up as expected.

This commit partially addresses #6983. We are able locally, with these changes
applied, to use filtering and sorting from a type module by calling the versions
of `UseFiltering` and `UseSorting` that take a type. Without the changes in this
commit, we get the "no convention registered" error.

This change does not close #6983 as it is still possible to encounter the "no
convention registered" exception and its suggested remedy of
"Call `AddFiltering()` on the schema builder" doesn't work.

From what we can see, and have detailed in #6983, no conventions registered with
the schema builder either directly or the defaults provided by `AddFiltering`
and `AddSorting` are available at the time that a type module is run.

The result of this commit is to allow the usage `UseFiltering` and `UseSorting`
with types created via a type module. The other option we are aware of is
detailed by @jimitndiaye in #6975.
Jimit routes around the convention problem by not using a convention at all
in his custom middleware. A close examination of `UseFilteringInternal` at
#6975 (reply in thread)
will show this lack of convention usage as key to his fix. Instead of going
the custom middleware route, we made these two small changes to Hot Chocolate.
We prefer this approach.