Create a price script that only accepts "large enough" deployments

[figurestudios]

With these variables, we can give providers the option to only accept deployments large enough. 0.1 vCPU / 512 Mi / 512 Mi deployments can lead to more trouble than they're worth and sometimes the provider wants to fill out all of their resources. There's a user in the Discord channel right now that has 1.1 PB of storage. While this is distributed across the network with NFS assuming that's possible on Akash, sometimes it's worth more just having large deployments.

cpu_requested
memory_requested
ephemeral_storage_requested
hdd_pers_storage_requested
ssd_pers_storage_requested
nvme_pers_storage_requested

I'm thinking that we can have these values plus boolean flags for providers if they don't care about a singular resource being utilized to the max.

12.8 <= cpu_mem_correlation   => 10   # disk   | memory
12.8 <= cpu_disk_correlation  => 10   # disk   | ephemeral + persistent
0.78 <= mem_disk_correlation  => 1.28 # memory | ephemeral + persistent

Which are dictated by:

min_cpu  = 10  # minimum number of threads used on a filled machine
min_mem  = 100 # minimum memory used on a filled machine (GB)
min_disk = 100 # minimum ephemeral + persistent disk used on a filled machine (GB)

So in this case, one would have to rent minimum 10 GB RAM and 10 GB disk (any kind) to get a bid back on a single thread. This would create for some inconsistencies, so we would also have to use some max values:

max_cpu  = 10  # minimum number of threads used on a filled machine
max_mem  = 128 # minimum memory used on a filled machine (GB)
max_disk = 128 # minimum ephemeral + persistent disk used on a filled machine (GB)

Now, nobody is allowed more than 12.8 GB memory or disk (any kind) per thread, or less than 10 GB memory or disk (any kind) per thread. It can still be more dynamic and be improved, but this would make it possible for a provider to feel safe in the way that all of their resources will be used equally across the machine (minimizing idle) and not having to worry about overselling one resource either. The example is a bit flawed because the range is so small, but it's just an example.