Restore the previous behaviour of checking the "OperationDateAndTime" value in the returned battery status, issuing a new battery check request if it hasn't changed. Also add the sleeps as discovered by @irekzielinski

Nissan may not return a start date, which is fine, but in that case we just have to return the data we have, instead of trying another 9 times and then returning it anyway.

`start_date is not None` can be simplified to just `start_date` thanks to @hencoappel

Move static method `_extract_start_date` out of `LeafStore` since it doesn't really belong there (Maybe it should move to pycarwings2?) and to keep black happy. Makes the code look much cleaner to me.

A few days of testing reveals that this method can return None. In an ideal world this function would just raise an exception, but here we are...

pycarwings2 can raise an exception if Nissan returns an empty list where battery records should be. My car stopped talking to me this week and this got the component completely stuck. Guard against this.

I got the logic wrong. If we failed to get an initial "start_date", we can't know if the data has been refreshed, we just have to trust the Nissan servers and return the first data they give us. (OR, if we did get a start_date, wait until it has changed)

server_info can be None, so make sure that it is valid before passing it to _extract_start_date.

If you leave the car for a couple of weeks, the API behaves even more strangely. Later calls to get_latest_battery_status will also fail, and there's nothing we can do about that, so just add TypeError to the list of exceptions which will log an error and return None

If the Nissan servers aren't responding, it seems unlikely that more than 3 retries will be helpful. If they are really stuck, reducing the limit reduces the load on the servers by ~3. Sometimes, the servers need a delay of about a minute to get the data, so at least 2 retries are often necessary.