Quota should not be hard-coded

[jshufro]

Quota exists in the system in rescue-api as well as rescue-proxy.

For rescue-api it is defined here:

rescue-api/services/credentials.go

Lines 31 to 57 in 4562a95

	type quota struct {
	// Max number of credentials that can be requested in a given time window.
	count uint
	// Time window in which the credential quota is calculated.
	window time.Duration
	// Duration a credential is valid for
	authValidityWindow time.Duration
	}
	var (
	// The delay between retries when creating a credential.
	// Values are taken from SQLite's default busy handler.
	dbTryDelayMs = []int{1, 2, 5, 10, 15, 20, 25, 25, 25, 50, 50, 100}
	quotas = map[credentials.OperatorType]quota{
	pb.OperatorType_OT_ROCKETPOOL: quota{
	count: 4,
	window: time.Duration(365*24) * time.Hour,
	authValidityWindow: time.Duration(15*24) * time.Hour,
	},
	pb.OperatorType_OT_SOLO: quota{
	count: 3,
	window: time.Duration(365*24) * time.Hour,
	authValidityWindow: time.Duration(10*24) * time.Hour,
	},
	}
	)

(ignore L43)

rescue-api will not issue new credentials when there are already count credentials issued to a node in the last window duration.
authValidityWindow is enforced by rescue-proxy, but important for rescue-api to have knowledge of.

As new entities want to run rescue node instances, they may wish to have separate quotas configured. Instead of hard-coding these values, they should be passed at runtime. If not passed, the current values should be used as defaults.

In terms of passing them at runtime, either a yaml file or structured cli args should suffice. Currently there are only 2 operator types, so cli flags aren't too cumbersome, but if we ever add a third it will be a lot, so perhaps a yml file is better.