Implement "any_chip" argument

[nbarlowATI]

As described in #692 , we sometimes have a situation where we know we want to play one of our chips, but it's not clear whether e.g. a triple_captain or a bench_boost would be more effective.
We can run with all chip gameweek arguments set to "0", but that will be a prohibitive number of possible combinations.
Instead, we can implement "--any_chip_week", and it will try all available chips for that gameweek.

The implementation would mostly be in airsenal/scripts/fill_transfersuggestion_table.py. The argument should be added to the argparse args. This main function also then creates a dict "chip_gameweeks", which is used in construct_chip_dict - I think that will be the key function to modify. Hopefully the resulting chip_gw_dict will be used both in the optimization itself and in the calculation of the number of expected outputs...

[subash774]

I can pick this up over the weekend if it's not already done yet?

[nbarlowATI]

That would be amazing @subash774 ! I didn't manage to find any time to do this in the end, so if you could, that would be great! Don't hesitate to ask if you have any questions..

[subash774]

Changing the model from dict to a data class would be good, I'll get the PR out first and then we can think about cleaning those up, will help with typing and scalability

[subash774]

@nbarlowATI
(:rubber-ducking:)
having a brief look at the current way of chip validation, not sure I understand how passing in 0 to the chips played is different?
we'd have to modify next_week_transfers to remove the validation and refactor construct_chip_dict to allow multiple chips being returned, so in theory, when running optimisation, we'd have to go through the same loop as setting them to 0 no? or do you mean we run each scenario of the available chips to non 0 gameweek so we cut down on the permutations?

[jack89roberts]

Hey @subash774 , thanks for looking at this! I think one option is that if --any_chip_week 24, for example, was passed to airsenal/scripts/fill_transfersuggestion_table.main, then the chip_gameweeks dict created there and passed to construct_chip_dict could look like this:

    chip_gameweeks = {
        "wildcard": 24,
        "free_hit": 24,
        "triple_captain": 24,
        "bench_boost": 24,
    }

Which would then require the chips_allowed / chip_to_play logic in construct_chip_dict to be updated so chips_allowed is used for cases like this, not only when the chip gameweek is set to 0 (I'm actually not sure why we have both chips_allowed and chip_to_play, so maybe that can be simplified, but it might be important for the optimization later on for some reason I'm forgetting about).

I don't think this would require any changes to next_week_transfers, unless you did look at whether chip_to_play can be removed, but again I might be missing something.