feat: new config for excluding fields on history-less resources

[theurichde]

What this PR does / why we need it:

This PR introduces a new diff field exclusion configuration for resources without a valid history

Which issue(s) this PR fixes:

Fixes #746

Does this PR introduce a user-facing change?

New diff field exclusion configuration for resources without a valid history

Additional Notes for your reviewer:

Review Checklist:

• Follows the developer guidelines
• Relevant tests are added or updated
• Relevant docs in this repo added or updated
• Relevant carvel.dev docs added or updated in a separate PR and there's
  a link to that PR
• Code is at least as readable and maintainable as it was before this
  change

Additional documentation e.g., Proposal, usage docs, etc.:

[theurichde]

Hello @praveenrewar!

I would like to have a brief review on this draft. I would like to ensure, that I am on the right track here. Unit tests are green, e2e tests are running right at the moment.

Of course, I will add unit tests for this specific feature, too.

Additionally, I would like to refactor it a bit more, but first let's see if the overall approach is the right one ;-)

[praveenrewar]

Hey @theurichde! Thank you so much for working on this ❤️
At first glance, it looks good to me, I will take a closer look at it in the morning.

[praveenrewar]

Hi @theurichde, the overall approach looks good to me, as you have mentioned we could do some refactoring, but I think we are in the right direction 🚀

We are completely ignoring the status field from diff, but we should probably ensure that status is available for ytt rebase rules and other places where it is used to determine if the resource is in the desired state (the changes shouldn't effect this functionality as we have an original copy of the resource for other uses but we should double check it to be on the safe side). The e2e tests should cover most of these scenarios except for ytt rebase rules using status field.

[praveenrewar]

I feel that the custom_wait_rules_test and order_test are creating a hindrance in this PR and they are not even related to the changes being made. Do you want to pair to quickly wrap this or would you be comfortable if I made a separate (quick) PR to refactor them so they are not effected by the changes being made in this PR (You have spent some time working on them so it's totally fine if you would want to continue and finish it here itself :) )?

[praveenrewar]

Do you want to pair to quickly wrap this or would you be comfortable if I made a separate (quick) PR to refactor them so they are not effected by the changes being made in this PR

I just created a PR to refactor those tests, let me know if you would want me to merge it and rebase this PR on top of it or feel free to copy those changes.

[theurichde]

want me to merge it and rebase this PR on top of it

Okidoki, go for it 😍

[praveenrewar]

Okidoki, go for it 😍

Done 🚀

[100mik]

LGTM!

[praveenrewar]

Thank you so much for working on this @theurichde 🙇🏻