Relax GPU affinity while maintaining Core affinity

Prior to the introduction of the LSB_GPU_NEW_SYNTAX=extend it was possible to have jobs using core affinity and be assigned to cores on a cpu that is not directly connected to the gpu that was assigned to the job. After the introduction it will allow the job only if there is atleast one core per gpu allocated from the cpu local to the gpu(s) assigned. When you have a mix of systems where some have gpus equally spread between the cpus and others where the gpus are all interconnected with an SXM2 fabric and then only connected to one of the cpus this can result in stranded resources in a non-exclusive job system. In many cases having access to a farther gpu is better than not scheduling a job at all. While removing core affinity removed the problem of the jobs not being scheduled it allows the jobs to use whatever cores they may want and breaks the feature of using core affinity to limit a job to only using as many cores as it requested in number of slots.
While it could be possible to have people submit some jobs that requested close gpus and others that requested far gpus that would lead to similar stranded capacity if they are not aware of what other jobs are requesting.

Prefering cpu cores near the gpu that is assigned would be good but having an option to relax to a preference but not a requirement would be the goal here.

We have multiple different gpu layouts 4 gpus with sxm2 connected to a cpu0 and none connected to cpu1, 8 gpus on pcie with 4 connected to cpu0 and 4 to cpu1, 10 gpus on pcie connected to cpu0 and none connected to cpu1. We also allow multiple users jobs on all nodes. Jobs can request any number of gpus and by amount of memory or type of gpu as we have many different gpu types available. Some jobs may need a particular gpu while others just need a gpu of some type and their locality is not strictly important. One of the jobs that are common that fit this would be a job that submits the work to the gpu(s) and then the cpu portion does very little other than wait for the results. These jobs tend to take advantage of our nodes with the sxm2 interconnect and spend the majority of their time working between the gpus and not interacting with the cpu. The second would be applications that farm out some portion of their compute to the gpu but are not strictly gpu applications. These can be very bursty but are not written to necessarily need a same numa close gpu to operate effectively. That is particularly true in codes that were written originally for running on a workstation. These applications tend to only need a single gpu but may request all or more resources than just cpu0 and in a single rooted gpu system that leaves cpu1 starved of gpus if core affinity is needed to fence the job.