Document deprecation and vulnerabilities on V3 search API docs

[KirillOsenkov]

As an example, if a package is deprecated, automatically add "deprecated" to the tag collection.

[khalidabuhakmeh]

I suggested this solution as it could work in the existing specification without altering the return structure of data. It's a stop-gap measure/solution.

https://learn.microsoft.com/en-us/nuget/api/search-query-service-resource#search-result

[joelverhagen]

Deprecated and vulnerable are available on the NuGet.org search service:

NuGetGallery/src/NuGet.Services.AzureSearch/SearchService/Models/V3SearchPackage.cs

Lines 70 to 74 in 0ec9961

	[JsonPropertyName("deprecation")]
	public V3SearchDeprecation Deprecation { get; set; }
	[JsonPropertyName("vulnerabilities")]
	public List<V3SearchVulnerability> Vulnerabilities { get; set; }

Strangely, this was never documented! I believe we were waiting for client to integrate with it before documenting it (to catch integration issues) but that's done... for a long time....

This one shows deprecated:
https://azuresearch-usnc.nuget.org/query?q=packageid:windowsazure.storage

This one shows deprecated + vulnerable:
https://azuresearch-usnc.nuget.org/query?q=packageid:BouncyCastle

@KirillOsenkov / @khalidabuhakmeh would it be fair to say this issue about deprecation specifically? Or is there other metadata in mind?

[khalidabuhakmeh]

Deprecation was the main use case I was thinking about but perhaps information like "prerelease" as well.

Although, those two elements you point to are a great addition. Thank you.

[joelverhagen]

I will update this issue to be "document deprecation and vulnerabilities properties in V3 search API", since I believe that is what is missing here.

Filling the tags property with deprecation or vulnerable info is not an ideal solution because the data model of tags is not rich enough to give the full story (e.g. alternate ID for deprecation or vulnerability severity), with some custom string encoding. Please let me know if you disagree.