FlurlResponse.Get*Async methods are missing cancellation token parameters

[AndyAtTib]

Flurl/src/Flurl.Http/FlurlResponse.cs

Lines 38 to 66 in 36a3fa2

	/// <summary>
	/// Deserializes JSON-formatted HTTP response body to object of type T.
	/// </summary>
	/// <typeparam name="T">A type whose structure matches the expected JSON response.</typeparam>
	/// <returns>A Task whose result is an object containing data in the response body.</returns>
	/// <example>x = await url.PostAsync(data).GetJson&lt;T&gt;()</example>
	/// <exception cref="FlurlHttpException">Condition.</exception>
	Task<T> GetJsonAsync<T>();
	/// <summary>
	/// Returns HTTP response body as a string.
	/// </summary>
	/// <returns>A Task whose result is the response body as a string.</returns>
	/// <example>s = await url.PostAsync(data).GetString()</example>
	Task<string> GetStringAsync();
	/// <summary>
	/// Returns HTTP response body as a stream.
	/// </summary>
	/// <returns>A Task whose result is the response body as a stream.</returns>
	/// <example>stream = await url.PostAsync(data).GetStream()</example>
	Task<Stream> GetStreamAsync();
	/// <summary>
	/// Returns HTTP response body as a byte array.
	/// </summary>
	/// <returns>A Task whose result is the response body as a byte array.</returns>
	/// <example>bytes = await url.PostAsync(data).GetBytes()</example>
	Task<byte[]> GetBytesAsync();

Is it worth adding cancellation token parameters to these methods, similar to IFlurlRequest.GetAsync([HttpCompletionOption completionOption = HttpCompletionOption.ResponseContentRead], [CancellationToken cancellationToken = default])

[SemaphoreSlim1]

"is it worth it?" I would say yes - forwarding cancellation tokens is a CA suggestion:
https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca2016