Added ability to define custom redirect function

[ghost]

Added the ability for users to define their custom redirect functions. This grants users wider flexibility when dealing with multiple redirect cases.

[bogdanfinn]

@sm0ke88 thank you for this contribution. Why are you not using the option to initialize the client with a custom redirect function?

https://github.com/bogdanfinn/tls-client/blob/master/client_options.go#L140

The drawback in changing the interface is that everyone who implements just the interface now needs to adjust his implementation.

Or are there valid use cases that one is switching between different redirect functions?

[ghost]

@sm0ke88 thank you for this contribution. Why are you not using the option to initialize the client with a custom redirect function?

https://github.com/bogdanfinn/tls-client/blob/master/client_options.go#L140

The drawback in changing the interface is that everyone who implements just the interface now needs to adjust his implementation.

Or are there valid use cases that one is switching between different redirect functions?

I have been utilizing a custom redirect function to address URL encoding parameters that consistently arise due to certain site configurations. However, I have encountered a specific scenario on the same site where I need to implement an additional custom redirect function within a specific part of the overall workflow. This prompted me to initiate the Pull Request (PR). It is worth noting that this method is rather specialized and will likely have infrequent use, yet it serves as a valuable alternative to manually managing redirects in the context of multi-step 302 responses.

For example, today I encountered a request that required four distinct redirects to obtain specific data. Instead of creating four individual handler functions to parse each step by disabling "Follow Redirects" and following them with self written implementations, I can conveniently create a custom CheckRedirect function to extract the required data from each step and assign it to a state variable.

[bogdanfinn]

@sm0ke88 i see the reasons.

One thing I'm still a bit worried about is the fact that we now have inconsistency in setting the custom redirect function. There are many ways currently in setting / changing the CheckRedirect function which might interfere and create unexpected side effects.

I think the best way would be to implement the function like this:

func (c *httpClient) SetRedirectFunc(redirectFunc customRedirectFunc) {
    c.config.customRedirectFunc = redirectFunc
    c.applyFollowRedirect()
}

This makes sure we do not have some overriding issues between the customRedirectFunction set by the setter and the custom redirect function set via the client options.