Update get_unpad_data patching for multipack

[chiragjn]

Fixes #1991 (at least attempts to)

The code for checking if a model has remote code is flawed where it assumes if someone is passing trust_remote_code then it must have remote code. That causes get_unpad_data patching to be missed if someone passes trust_remote_code: True breaking mulit packed sample packing with flash attention

This PR changes that to rely on auto_map defined in model's config.json

Plus additionally removes the pre 4.43 transformers patching code.

How has this been tested?

So far, manually, but would be nice to add tests. First would like to get some review feedback

Requesting review from @winglian and @NanoCode012

[NanoCode012]

Is any handling needed if"_get_unpad_data" is not available? For ex, throw error to say packing not available?

[chiragjn]

Wanted to get an opinion on this, I am not sure myself. Maybe it can be an error for some known model types where we expect it and warnings for others?

[NanoCode012]

Hm, I think it's good to have a check in case upstream changes a model type we support without our knowledge.

else:
  if {model_type} in list_of_known_working_types:
     raise Error

[winglian]

I think once we address the last 2 suggestions, this should be good to go. We should also make sure we manually run the multigpu tests before merging this PR.

[NanoCode012]

I think we should add a small e2e test for this. Perhaps similar to tests/e2e/test_lora_llama.py but for fft with trust_remote_code on. I'll run a few e2e tests first.

[NanoCode012]

Manually Tested CI:

• e2e multi-gpu as-is
• e2e rebased to main
• e2e multi-gpu rebased to main

Edit: Having some issues verifying the last two runs, re-running.

Edit2: Double-checked those tests are working.