Allow bypassing of x-forwarded header removal

[rkargMsft]

Addresses #2727

[rkargMsft]

Looks like AddXForwarded similarly removes the Forwarded headers and needs similar treatment.

[adityamandaleeka]

Haha, I did some digging and found this: #1070 (comment)

[MihaZupan]

I agree that having the extra argument be removeAllXForwardedHeaders instead of suppressRemoveAllXForwardedHeaders is better.

The annoying part is that the current logic doesn't always remove the other header. AddForwarded does it conditionally.

yarp/src/ReverseProxy/Transforms/ForwardedTransformExtensions.cs

Lines 188 to 201 in 41e563c

	if (action == ForwardedTransformActions.Off)
	{
	return context;
	}
	if (byFormat != NodeFormat.None || forFormat != NodeFormat.None || useHost || useProto)
	{
	var random = context.Services.GetRequiredService<IRandomFactory>();
	context.RequestTransforms.Add(new RequestHeaderForwardedTransform(random,
	forFormat, byFormat, useHost, useProto, action));
	// Remove the X-Forwarded headers when an Forwarded transform is enabled
	TransformHelpers.RemoveAllXForwardedHeaders(context, ForwardedTransformFactory.DefaultXForwardedPrefix);
	}

I'm not actually sure why someone would want to add a no-op Forwarded transform like that.
I'd be okay with making a small breaking change here and have the new default be that the other header gets removed unconditionally (well, conditioned on the new argument only).

[rkargMsft]

I can swap the parameter naming.

I'm not sure what the best way to handle action == ForwardedTransformActions.Off is because, as you say, it doesn't make sense to call AddForwarded with that action. If it were a new method then I'd propose validation that would throw if it was Off because, just don't call AddForwarded. I think that since it exists with the current behavior (do nothing if .Off) that it be kept as is. I think it would be odd to have the desired behavior be that .AddForwarded(..., action: ForwardedTransformActions.Off) be to do nothing with Forwarded headers but add transforms to remove the XForwarded headers.

[MihaZupan]

Thanks.

Mind adding a few tests for these?

[rkargMsft]

Minor pain point is that targeting the alpha SDK does add some friction to contributing

[MihaZupan]

Thank you.

Did you run into SDK issues even after running build.cmd from the root?
(it's not that common of a step in general, but is a thing for most dotnet/* repos)

[rkargMsft]

I was not aware of that. Running build.bat and startvs.bat worked great.

Someone should put that in the Readme, maybe somewhere near the top in a Build section or something. Wait a minute...

Narrator: The Readme already tells you exactly how to do this.