Add `Access-Control-Allow-Origin: *` and more sensible `Retry-After` headers to HTTP 429 Nominatim responses

[mstock]

Recently, I somewhat accidentally triggered the rate limit on nominatim.openstreetmap.org using a browser based application which uses it for geocoding (it's an application from the wider OSM ecosystem, which is currently apparently a bit broken in multiple regards). When inspecting the error messages in the browser console, the browser mentioned that the HTTP 429 response is lacking an Access-Control-Allow-Origin: * header, which means that the JavaScript code only gets a generic exception (something like NetworkError) instead of the actual error response. Besides that, I also noticed the Retry-After: 0 header (apparently, just like somebody else recently did, too).

I think it would be nice to have an Access-Control-Allow-Origin: * header in such a case so that browser based applications can actually notice that they're misbehaving - if they just get a generic exception, this may be misinterpreted as some low-level error and trigger some retry logic. Similarly for the Retry-After header - if an application actually interprets it, it would simply continue to hammer the API when it gets 0. So it might be good to set it to some realistic value after which a retry should succeed again - or to simply leave it out completely.

Obviously, applications which run into the rate limit should be changed to make less requests or use their own Nominatim instance. However, the way the API (or rather what sits in front of it) currently behaves doesn't seem to be ideal or even counter-productive in cases where an application would correctly handle HTTP 429 responses.

[pnorman]

I think we have two routes to 429 errors with bost nominatim and fastly capable of generating them, so both need reviewing.

[lonvia]

Done that for the Nominatim side: openstreetmap/chef@0b701b6