internal: non-strict RFC ETag format support

[borisovdev]

For some caldav providers, it wasn't possible to unmarshal unquoted text for etag

Referenced to #165, #69

[emersion]

This is non-standard, so not sure I want to maintain this.

This also unnecessarily uses regular expressions, and falls apart when marshaling etags.

[borisovdev]

This is non-standard, so not sure I want to maintain this.

This also unnecessarily uses regular expressions, and falls apart when marshaling etags.

Thanks for the quick reply and your time!
Yes, I have already familiarized myself with other similar issues. The reality is that many providers do not strictly follow the RFC in this place. Should we send people to live in a fork just because the rules say so? Often we do, but it seems not in this case. Please give it some thought:)

Thanks for pointing out MarshalText, I should be more careful. I'm marking PR as draft and will finalize it as soon as I have free time.

[borisovdev]

I like to clarify details, to avoid misunderstandings) We are talking about https://datatracker.ietf.org/doc/html/rfc2616#section-3.11, right?

About the review:

This also unnecessarily uses regular expressions and falls apart when marshaling etags.

1. removed regexp from implementation
2. I thought of possible problems with marshaling in my head, but didn't find them. In the extended implementation of UnmarshalText an unquoted string is returned anyway. I added new tests and modified the old one

This is non-standard, so not sure I want to maintain this.

the fate of this item is in your hands:)

Rebased and updated the branch

[Miha-ha]

I also encountered this problem when using DavMail. The edits are very minimal and I don't want to make a fork for this. I am sure that with these changes it will only get better!