Resolve recursive language definations causing incorrect x-ms-pageable methods

[chamons]

Description

This is a second attempt at #1281, with a bit of a deeper dig into how we ran into the situtation.

Pavel pointed out during a discussion that we really shouldn't be seeing any of these "extra" methods at the level #1281 was filtering them out.

After applying industrial strength bisect I was able to come up with this test case:

!CodeModel 
operationGroups:
  - !OperationGroup 
    operations:
      - !Operation 
        language: !Languages 
          default:
            paging:
              nextLinkName: nextLink
      - !Operation 
        language: !Languages 
          default:
            paging:
              nextLinkName: nextLink
              nextLinkOperation: !Operation &ref_17
                language: !Languages 
                  default:
                    paging:
                      nextLinkName: nextLink
                      nextLinkOperation: *ref_17
      - *ref_17

In it this code:

            foreach (var op in v.OperationGroups.First().Operations)
            {
                var paging = op.Language.Default.Paging;
                bool hasNextOperation = paging?.NextLinkOperation != null;

would return true for the second and third operation in my simplified model but the third (*ref_17) would differ in the "full" autorest.csharp model.

The culprit was surprisingly:

-    internal partial class Language : IDictionary<string, object>
+    internal partial class Language

For some, honestly unknown, reason YamlDotNet would not handle this case correctly as long as we implemented the dictionary interface. I decided against deep diving into that 3rd party dependency to understand this further. This already cost too many days. I did try bumping to latest, which failed for unrelated reasons but did not change this behavior.

Removing the IDictionary interface required adding a few fields (header, summary) that were being indirectly handled, and may require more when I test this with azure-sdk-for-net this afternoon.

Test case included for #1056 in particular.

The removals in the paging test suites are expected.

Checklist

To ensure a quick review and merge, please ensure:

• The PR has a understandable title and description explaining the why and what.
• The PR is opened in draft if not ready for review yet.
  • If opened in draft, please allocate sufficient time (24 hours) after moving out of draft for review
• The branch is recent enough to not have merge conflicts upon creation.

Ready to Land?

• Build is completely green
  • Submissions with test failures require tracking issue and approval of a CODEOWNER
• At least one +1 review by a CODEOWNER
• All -1 reviews are confirmed resolved by the reviewer
  • Override/Marking reviews stale must be discussed with CODEOWNERS first

[pakrym]

Does this project add something new on top of the existing test-server paging swagger?

[chamons]

Those were in autorest.testserver and this felt possibly specific to C#'s handle of x-ms-pagable. I have no strong feeling here, I can push them up if you think that's preferable.

[chamons]

Was able to generate azure-sdk-for-net with local nuget with no issues (fwict) through gen code and building.

Will redo test tomorrow.

[chamons]

There we go, removed the specific test and added it to the general paging test suite.

[chamons]

Wait for next week.

[chamons]

Decide to land it now and not land bump PR until next week.