Support prebuilt OpenApiOperation in EndpointMetadata

[captainsafia]

As part of the work outlined in dotnet/aspnetcore#40676 and implemented in dotnet/aspnetcore#41238, we're experimenting with providing a package that allows users to generate and modify OpenApiOperation metadata directly on endpoints.

In this new workflow, a user can annotate their endpoint like so:

app.MapGet("/foo", () => ...)
  .WithOpenApi();

Which will generate the OpenApiOperation directly and add it to the endpoint metadata. Users can also do:

app.MapGet("/foo", () => ...)
  .WithOpenApi(operation => {
     return modifyMyOperation(operation)
  });

Which will add an OpenApiOperation to metadata with the modifications that the user provides.

This PR checks to see if there already exists OpenApiOperation metadata for an endpoint and uses that over the generated variety.

[captainsafia]

@domaindrivendev Thoughts on this?

[domaindrivendev]

Hi @captainsafia - happy to merge this as it's relatively straightforward. However, I do have a couple of questions around the work outlined in dotnet/aspnetcore#40676:

• If I'm understanding correctly, the longer term goal is to provide mapping of internal metadata to OpenApi types in a new package. Wouldn't this essentially replace the core of what Swashbuckle does? If so, that raises major questions around how much effort should continue going into Swashbuckle itself. cc @bradygaster
• Furthermore, I believe (from many years of experience) that perfecting that mapping is extremely difficult, particulary when it get's into mapping C# models to OpenApiSchema instances, accounting for serializer behavior etc. So, interested to know exactly how far the new library will go. For example, will it account for serializer behavior, data annotations etc.?