refactor!: 450 - finalizing the breaking changes

[monsieurtanuki]

Deleted files:

• page.dart: deprecated from 2022-04-20
• product_list_query_configuration.dart: deprecated from 2022-08-03
• to_be_completed_configuration.dart: deprecated from 2022-08-03

Impacted files:

• image_helper.dart: removed code deprecated from 2022-08-18, and so we can get rid of package image
• insight.g.dart: generated
• nutriments.dart: removed 1655 (!) lines of code deprecated from 2022-10-04 - it was not urgent but now seemed a good opportunity
• nutriments_helper.dart: removed code deprecated from 2022-10-04 - it was not urgent but now seemed a good opportunity
• open_food_api_client.dart: removed code deprecated from 2022-01-22 and 2022-07-26
• openfoodfacts.dart: removed export deprecated from 2022-04-20
• product.dart: fixed typo
• product.g.dart: generated
• pubspec.yaml: removed deprecated dependency on image; upgraded versions
• README.md: added info about how to deal with 2.x.x breaking changes

What

• Some minor cleaning after the most important PRs are merged.

Fixes bug(s)

• Fixes: pub.dev score from 130 to 120 :( #450

[M123-dev]

Looks great @monsieurtanuki

[monsieurtanuki]

Thank you @M123-dev: now I think we're ready for 2.0.0!
No rush though, as I've noticed that Smoothie only used 1.27.1. I'm going to upgrade Smoothie to off-dart 1.30.1 first.

[M123-dev]

Yeah, if I have time later I'm going to work on #339 and maybe #514

[monsieurtanuki]

Regarding #514: we cannot apply the same rules for off-dart and for Smoothie, for at least one good reason - for libraries like off-dart inner imports should use the relative syntax, and in the current Smoothie rules we are supposed to use the package syntax. Maybe "dart library" specific rules? But basically that would mean whatever pub.dev requires, perhaps a bit stronger.

Regarding #339, last time we discussed it was a year ago. Please check if that would still make sense, and state what you plan to code (would be "create a separate class for all the Robotoff methods", wouldn't it?).

[M123-dev]

Your worries for #514 make sense, that's why it was more of an optional thing, I have to check if all the rules make sense and probably override some of them.

[monsieurtanuki]

@M123-dev It was not a worry, it was a fact: I tried and saw tons of warnings!

I believe we don't have to wait for you to implement #514 for version 2.0.0, because:

• either the impact will be HUGE (e.g. all constants in camelCase) and that wouldn't be a good idea at all (too much unpleasant work for developers that use off-dart)
• or there will be no impact at all, breaking change wise (e.g. specifying the type before each empty [])

[M123-dev]

Okay makes sense, if there is no urge I would start writing some documentation today and tomorrow
Also thinking about the two different classes for robot off, I don't think I make a big difference for us, it just hides it more from the package users. If it's in the same class, they might stumble upon it, so I have crossed it off my list