bin concept of custom finders

[chris48s]

Refs https://app.asana.com/0/1204880927741389/1208958646411295/f

[chris48s]

For the sake of not making a breaking API change, I am going to keep the key in the object but it is just always null in 100% of cases.

[symroe]

Don't forget that this is basically not a supported API. If the devs.DC code doesn't consume this, then there's nothing to break. If it does, then I suggest we come back and remove this when that code doesn't rely on it.

[chris48s]

Yeah I think I want to get rid of any code that might be expecting this value to exist in devs.DC first then come back and remove it. In some ways, I may have approach this backwards.

[chris48s]

Properly removing this has knock-on effects in a bunch of places that have code to consume the value which we can also remove.

Again for the sake of not making a breaking change, I think I want to leave the key in the object on devs.DC but I do want to remove stuff like https://developers.democracyclub.org.uk/api/v1/#notes-and-tips-2 and just say "this field used to be a thing, but now it is always null" or whatever.

[coveralls]

coverage: 71.774% (-0.04%) from 71.811%
when pulling a685f39 on bin-custom-finder20250123
into 00213d7 on master.

[symroe]

I've not checked everywhere in the code here, but this looks fine.

If we're only keeping the field in the API for public reasons, then I'd rather we do that in the devs.DC code rather than here.

There are general problems with shoving an object from this service into devs.DC and then re-broadcasting it, so let's not make things harder for ourselves by supporting legacy properties across them both

[chris48s]

Probably not one to deal with in this PR, but I wonder if it is actually useful to keep maintaining sandbox responses on this repo now it is private?

[chris48s]

It should be safe to completely remove the key now that devs.DC does not rely on it