Allow raster source tile updates to re-trigger tile request that failed previously

[wagewarbler]

Events where tile sources are updated should be handled differently from other types of source updates. Currently if a tile errors, it won't be re-requested presumably on account of not wanting to waste traffic on a previously failed fetch. The fetch may no longer be pointless however if the "source's source" has been updated. In this situation, old tile requests that failed are no longer relevant. It's in effect like a new source in the old source's place.

This PR fixes a bug where fetches that previously failed prevent further fetches with with new tile URLs.

This could likely be applied to vector tiles as well if the approach makes sense!

A map loaded with failed tile requests. Previously a change to the date wouldn't trigger new fetches. With this change in place, new tiles are requested as expected:

Screencast.from.2024-10-24.16-25-07.webm

Launch Checklist

• Confirm your changes do not include backports from Mapbox projects (unless with compliant license) - if you are not sure about this, please ask!
• Briefly describe the changes in this PR.
• Link to related issues.
• Include before/after visuals or gifs if this PR includes visual changes.
• Write tests for all new functionality.
• Document any changes to public APIs.
• Post benchmark scores.
• Add an entry to CHANGELOG.md under the ## main section.

[HarelM]

Can you better describe the scenario that you would change the raster source definition and expect it to be reloaded? Wouldn't removing the source and adding a different one is a better approach?

[wagewarbler]

Can you better describe the scenario that you would change the raster source definition and expect it to be reloaded?

Sure. Updating a date (or any attribute) filter for an existing source. For instance going from this:

https://<some-base-url>/tiles/WebMercatorQuad/4/5/5?datetime=2024-10-03T16:30:00Z/2024-10-03T17:30:00Z

To this:

https://<some-base-url>/tiles/WebMercatorQuad/4/5/5?datetime=2024-10-04T16:30:00Z/2024-10-04T17:30:00Z

Wouldn't removing the source and adding a different one is a better approach?

That's a valid question but possibly beyond the scope of this PR. This PR is just attempting to fix behavior that effectively derails a raster tile source from showing any further tiles once it gets a 404 or other error. That said, I think your question is a valid one in big picture kind of way and could potentially spawn further work. Correct me if I'm wrong, but currently this lib is set up so that cross-fading is only possible when navigating within an existing layer source. In other words, zooming in and out or calling RasterTileSource > setTiles as we added in #3208. A different approach would be to remove an old layer source and add a new one, but without the cross fading this would be a jerky experience for the user.

[HarelM]

Yeah, it might have been that the original design expected the source to be immutable or sometime similar, which we broke with the addition of setTiles.
Other sources are not really immutable, so fixing this probably makes more sense now.
Thanks for the context!

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.22%. Comparing base (95cfbdb) to head (40cd814).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4890   +/-   ##
=======================================
  Coverage   90.21%   90.22%           
=======================================
  Files         265      265           
  Lines       37974    37977    +3     
  Branches     2569     2567    -2     
=======================================
+ Hits        34257    34263    +6     
+ Misses       2848     2846    -2     
+ Partials      869      868    -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[HarelM]

Please add a changelog entry and I'll merge this.

[HarelM]

Can you resolve conflict? Probably related to changelog file...