Need to Determine and Document Intended Package Url Handling

[brodriguez8774]

Various instances of URL handling has come up as the project has grown.
All of the following assumes context of within the assertResponse() custom assertions.

Originally there were three:

• The url used to resolve the request. This determined what view was accessed.
• The url for expected_url, used 90% of the time when asserting that we made it to the correct page.
• The url for expected_redirect_url, used the same way as expected_url, but only in instances when the page experiences a 302 redirect while resolving the request.

At some point early on, the "basic request url" was given the option to provide args/kwargs, and magically auto-resolve within the assertResponse() if desired. This was actually incredibly convenient.

The expected_url was intentionally left as-is, where it wouldn't auto-magically attempt to resolve. The exact desired literal url needed to be provided, to give a way to ensure that the above "basic request url" resolved to the expected endpoint. This is meant for testing, so some ability to be explicit is good.

However, at some point, expected_redirect_url was updated to handle similarly to the "base request url", by being given the option to auto-magically resolve as a reverse url with args/kwargs, within the assertion. I don't remember the reasoning for this but it effectively goes against the logic of why expected_url WASN'T given this option.

Now the two handle differently, which is not intuitive. I'm tempted to side with the original logic behind expected_url, but reverting would result in breaking changes.

---

This is now more complicated, due to recent changes in late 2024.
There is now the concept of final_url, which is effectively "the final endpoint url the response ends up at", which may be useful if the user doesn't really care about redirects, and only ever wants to verify the final url the response resolves with.

Using final_url makes even more sense when accounting for new possible sub-assertions within assertResponse() now. If one wants to check for redirects (or lack thereof), this can now effectively been done with the combination of the expected_status and view_should_redirect args.

Ultimately, I'm tempted to make expected_final_url behave similarly to expected_url, which makes expected_redirect_url the odd one out, an d it probably should be reverted/changed before 1.0 release.