BS: Max MaxExpTime configurable

[oncilla]

This PR makes the MaxExpTime for segments configurable through the policy.

fixes #2968

---

This change is 

[scrye]

Reviewed 14 of 14 files at r1.
Reviewable status: all files reviewed, 4 unresolved discussions (waiting on @oncilla)

---

go/beacon_srv/main.go, line 385 at r1 (raw file):

			MTU:        uint16(topo.MTU),
			Signer:     signer,
			MaxExpTime: maxExpTimeFactory(t.store, beacon.PropPolicy),

Rename MaxExpTime to something to more clearly indicate it's a function callback. It sounds static right now, which is misleading, it needs to have a verb. Something like GetMaxExpTime or ComputeMaxExpTime.

---

go/beacon_srv/main.go, line 385 at r1 (raw file):

			MTU:        uint16(topo.MTU),
			Signer:     signer,
			MaxExpTime: maxExpTimeFactory(t.store, beacon.PropPolicy),

What is the reasoning behind making this a callback instead of a number?

---

go/beacon_srv/internal/beacon/policy.go, line 186 at r1 (raw file):

	// MaxExpTime indicates the maximum value for the expiration time when
	// extending the segment.
	MaxExpTime *spath.ExpTimeType `yaml:"MaxExpTime"`

What happens if the value in the yaml file exceeds the maximum for uint8?

---

go/beacon_srv/internal/beacon/store.go, line 106 at r1 (raw file):

func (s *Store) MaxExpTime(policyType PolicyType) spath.ExpTimeType {
	switch policyType {
	case UpRegPolicy:

How does MaxExpTime impact UpSegmentRegistration/DownSegmentRegistration/CoreSegmentRegistration?

---

go/beacon_srv/internal/config/sample.go, line 41 at r1 (raw file):

const policiesSample = `
# Output a sample policy file by providing the -help-policy flag.

💯

[oncilla]

Reviewable status: 7 of 17 files reviewed, 4 unresolved discussions (waiting on @scrye)

---

go/beacon_srv/main.go, line 385 at r1 (raw file):

Previously, scrye (Sergiu Costea) wrote…

Rename MaxExpTime to something to more clearly indicate it's a function callback. It sounds static right now, which is misleading, it needs to have a verb. Something like GetMaxExpTime or ComputeMaxExpTime.

Done.

---

go/beacon_srv/main.go, line 385 at r1 (raw file):

Previously, scrye (Sergiu Costea) wrote…

What is the reasoning behind making this a callback instead of a number?

The store has ownership of the policies.
In the future we probably want support for reloadable policies.
Also, at some point we had a discussion, that we might want to store the policies in the database to ensure a consistent state (when they get more complex)

Having it as a callbacks gives us the following:

1. Simple refactor now. (otherwise we need a way to extract the information and initialize the extender with it)
2. Simple policy reloading

---

go/beacon_srv/internal/beacon/policy.go, line 186 at r1 (raw file):

Previously, scrye (Sergiu Costea) wrote…

What happens if the value in the yaml file exceeds the maximum for uint8?

parsing will fail.

---

go/beacon_srv/internal/beacon/store.go, line 106 at r1 (raw file):

Previously, scrye (Sergiu Costea) wrote…

How does MaxExpTime impact UpSegmentRegistration/DownSegmentRegistration/CoreSegmentRegistration?

It is used when terminating the segment to compute the MaxExpTime of the last hop field.

[scrye]

Reviewed 10 of 10 files at r2.
Reviewable status: complete! all files reviewed, all discussions resolved

[scrye]

Reviewed 2 of 2 files at r3.
Reviewable status: complete! all files reviewed, all discussions resolved