date parsing: Cookie expiry fallback

[Tuniwutzi]

This PR suggests a different behavior for parsing cookie expiry dates.

Two changes were made:

1. Add Curl_parse_expiry which is used to parse HTTP cookie expiry dates. The only difference to curl_getdate is that it does not return an error in case of PARSEDATE_LATER. This means that cookies with expiry later than 2038 do not get parsed as session cookies any more, but as cookies with the latest possible expiry timestamp.
   Reason: I use curl in a project where the server returns cookies with expiry dates of 2087 and later (for whatever reason). Curl treating these as session cookies and ignoring them upon restart caused big issues and seems counter-intuitive to me.
2. Change the behavior of parsedate to not return TIME_T_MAX when we are unsure if we can represent the given date in time_t. Instead, return the timestamp for 01.01.2038, 00:00 in the timezone specified in the date string.
   Reason: This ensures that we never return a later timestamp than specified in the datestring, so the returncode PARSEDATE_LATER does not lie. Note that this does not change the behavior of curl_getdate, which returns an error if the returncode is not PARSEDATE_OK.

Note: I added Curl_parse_expiry to avoid a change to the behavior of the public interface by changing curl_getdate.

ToDo:

• Make parsedate consistent by replacing this code:

  if(yearnum < 1903) {
      *output = TIME_T_MIN;
      return PARSEDATE_SOONER;
  }
  

  With an equivalent mechanic to that used in overflow.
• Make Curl_parse_expiry deal with PARSEDATE_SOONER the same way it deals with PARSEDATE_LATER for consistency
• Add unit tests for this behavior

[bagder]

I think the reasoning and fix are perfectly convincing. It would be lovely with a unit test that verifies that this actually work like this too (and will avoid future regressions).

[Tuniwutzi]

Good, as soon as I have time I will address the todos in the description and add a unit test.

[Tuniwutzi]

I tried to add a unit test but I'm not sure how to do it. I'll try to figure it out when I have some time again, but if someone has pointers for me it would be appreciated.

[bagder]

There's a little README describing how to write and run unit tests.

If you run into problems when following that, please ask and we can help out (and update the docs if necessary)!

[danielgustafsson]

@Tuniwutzi How are you going with the unit test, do you need any assistance?

[Tuniwutzi]

Unfortunately I was having some issues when I tried adding and running a new test. Then a lot of other work came up for me and I forgot to finish this.

@danielgustafsson Any assistance would be greatly appreciated, since I'm short on time at the moment. So if you want to lend a hand, I would definitely not complain! Otherwise I'll hopefully get to it sometime in December.

[bagder]

This ensures that we never return a later timestamp than specified in the datestring, so the returncode PARSEDATE_LATER does not lie

Why is it important? Out of all "later" dates we can specify, most of them will be larger...